Skip to main content

[JIRA] Commented: (SIPSERVLET_SPEC-25) Clarification on how to handle Replaces in JSR 289

  • From: "binod (JIRA)" < >
  • To:
  • Subject: [JIRA] Commented: (SIPSERVLET_SPEC-25) Clarification on how to handle Replaces in JSR 289
  • Date: Tue, 11 Feb 2014 07:58:49 +0000 (UTC)
  • Auto-submitted: auto-generated


    [ 
https://java.net/jira/browse/SIPSERVLET_SPEC-25?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=373104#action_373104
 ] 

binod commented on SIPSERVLET_SPEC-25:
--------------------------------------

Right, it is the applications responsibility to respond with 481, if a match 
for replaces header is not found. To clarify this, we can add a note saying 
that

"However, if the container does not find a dialog matching Join or Replaces 
header, then the container will not respond with 481 directly. Applications 
may choose to respond to the request with 481". 

> Clarification on how to handle Replaces in JSR 289
> --------------------------------------------------
>
>                 Key: SIPSERVLET_SPEC-25
>                 URL: https://java.net/jira/browse/SIPSERVLET_SPEC-25
>             Project: sipservlet-spec
>          Issue Type: New Feature
>            Reporter: bpulito
>            Assignee: binod
>
> RFC 3891 states this when an INVITE is received with a Replaces header: "If 
> no match is found, the UAS rejects the INVITE and returns a 481 
> Call/Transaction Does Not Exist response. likewise, if the Replaces header 
> field matches a dialog which was not created with an INVITE, the UAS MUST 
> reject the request with a 481 response. " 
> JSR 289 states that: 
> "1) If a container supporting [RFC 3911] or [RFC 3891] receives an initial 
> INVITE request with Join or Replaces header, the container must first 
> ensure that the request passes the RFC-defined validation rules." 
> JSR 289 also states that: 
> "If no SipSession matching the tuple is found, the container MUST pass the 
> request to the Application Router as an untargeted request, i.e., where the 
> SipTargetedRequestInfo argument to getNextApplication() is null." 
> This is a contradiction between the RFC and the JSR. So its not clear if 
> the SIP container needs to override the validation rules of the RFC. If the 
> request is routed to a UAS application, and there is no match, is it the 
> applications responsibility to respond with a 481? 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://java.net/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[JIRA] Commented: (SIPSERVLET_SPEC-25) Clarification on how to handle Replaces in JSR 289

binod (JIRA) 02/11/2014
 
 
Close
loading
Please Confirm
Close