Subject: [Sip] Request/response question...

From: <[email-masked]>
Date: Wed, 11 Jun 2008 17:55:19 -0400

I have a basic SIP question.  The way I understood RFC3261, the "To:" header
field in a response  has to match the "To:" header field of the
corresponding request (if no To tag is present in the request).  This is
true for 99% of the SIP conversations I've seen but not for the (real-life)
example below (note that the "To:" header fields differ).  Wireshark has no
problem with analyzing this SIP conversation, so I suspect I'm
misinterpreting the RFC.

Can the "To:" header fields be different, and if so, how can the response be 
correlated to the request?

#
# The request
#
INVITE sip:[email-masked]:10000 SIP/2.0
Via: SIP/2.0/UDP 192.168.5.156:10000;branch=z9hG4bK-762646f2
From: 555-482-0690
<sip:[email-masked]:10000>;tag=716ff48d4ef52332o0
To: <sip:[email-masked]:10000>
Remote-Party-ID: 555-482-0690
<sip:[email-masked]:10000>;screen=yes;party=calling
Call-ID: [email-masked]
CSeq: 102 INVITE
Max-Forwards: 70
Proxy-Authorization: Digest
username="15554820690",realm="69.59.242.85",nonce="1489356920",uri="sip:[email-masked]:10000",algorithm=MD5,response="095bb689741268d970ca807964d58a73"
Contact: 555-482-0690 <sip:[email-masked]:10000>
Expires: 240
User-Agent: 001310757539 Linksys/RT31P2-3.1.6(LI)
Content-Length: 316

#
# The response
#
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.5.156:10000;branch=z9hG4bK-762646f2
From: 555-482-0690
<sip:[email-masked]:10000>;tag=716ff48d4ef52332o0;natted=24.235.117.242
To: <sip:[email-masked]:10000>;tag=1645248237
Call-ID: [email-masked]
CSeq: 102 INVITE
Contact: <sip:[email-masked]:10000>
Max-Forwards: 15

#
# The relevant RFC section
#
8.2.6.2 Headers and Tags

   The From field of the response MUST equal the From header field of
   the request.  The Call-ID header field of the response MUST equal the
   Call-ID header field of the request.  The CSeq header field of the
   response MUST equal the CSeq field of the request.  The Via header
   field values in the response MUST equal the Via header field values
   in the request and MUST maintain the same ordering.

   If a request contained a To tag in the request, the To header field
   in the response MUST equal that of the request.  However, if the To
   header field in the request did not contain a tag, the URI in the To
   header field in the response MUST equal the URI in the To header
   field; additionally, the UAS MUST add a tag to the To header field in
   the response (with the exception of the 100 (Trying) response, in
   which a tag MAY be present).  This serves to identify the UAS that is
   responding, possibly resulting in a component of a dialog ID.  The
   same tag MUST be used for all responses to that request, both final
   and provisional (again excepting the 100 (Trying)).  Procedures for
   the generation of tags are defined in Section 19.3. 

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jun 2008 18:14:42 -0400

> correlated to the request?

The To in the response can only differ from that in the request because 
of the addition of a tag= parameter if there wasn't one in the request. 
The rest of the To-header must be the same.

The matching of the response to the request is based on the branch 
parameter in the Via, so that isn't the problem.

	Paul

---

From: [email-masked]
Date: Wed, 11 Jun 2008 18:15:56 -0400

From: <[email-masked]>

   Can the "To:" header fields be different, and if so, how can the
   response be correlated to the request?

The RFC does require the To (and From) headers to match, but everybody
believes that is an obsolete requirement and will probably be relaxed
in the near future.  So generate requests with matching To/From
headers, but do not depend on them.

Requests and responses are correlated by the branch parameters in
their Via headers.

Requests are grouped into dialogs by their "dialog identifiers", that
is, call-id/to-tag/from-tag.

Dale

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 11 Jun 2008 17:23:22 -0500

See section 3 of http://www.ietf.org/rfc/rfc4916.txt. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of [email-masked]
> Sent: Wednesday, June 11, 2008 14:55
> To: [email-masked]
> Subject: [Sip] Request/response question...
> 
> 
> I have a basic SIP question.  The way I understood RFC3261, 
> the "To:" header field in a response  has to match the "To:" 
> header field of the corresponding request (if no To tag is 
> present in the request).  This is true for 99% of the SIP 
> conversations I've seen but not for the (real-life) example 
> below (note that the "To:" header fields differ).  Wireshark 
> has no problem with analyzing this SIP conversation, so I 
> suspect I'm misinterpreting the RFC.
> 
> Can the "To:" header fields be different, and if so, how can 
> the response be correlated to the request?
> 
> 
> #
> # The request
> #
> username="15554820690",realm="69.59.242.85",nonce="1489356920"
> ,uri="sip:[email-masked]:10000",algorithm=MD5,response
="095bb689741268d970ca807964d58a73"

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Jun 2008 18:27:41 -0400

> headers, but do not depend on them.

AFAIK there is no agreement that they shouldn't match in a request and 
its *response*. Most do now agree that they might change for subsequent 
requests within a dialog.

At one point there may have been a little talk about changing the To in 
a response to indicate the actual identity of the called party. But once 
it was realized there was no good way to authenticate that we stopped 
talking about it. (At least that is what I remember.)

	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 11 Jun 2008 21:24:03 -0500

> talking about it. (At least that is what I remember.)

Changing it in a response is critical to extending RFC 4474 for use in  
responses where there are certificates available in the UAs or where  
identity-based signatures are used.

In other words, IF we solve the PKI problem and don't get distracted  
by the unanticipated respondent problem, then we NEED variant To in  
responses to be able to se response-identity, because connected- 
identity is a) late in a dialog and b) useless for non-dialog  
transactions, like MESSAGE.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 12 Jun 2008 08:33:18 -0400

ok, I stand corrected.

	Thanks,
	Paul

Dean Willis wrote:
> In other words, IF we solve the PKI problem and don't get distracted by 
> the unanticipated respondent problem, then we NEED variant To in 
> responses to be able to se response-identity, because connected-identity 
> is a) late in a dialog and b) useless for non-dialog transactions, like 
> MESSAGE.
> 
> -- 
> Dean
> 
>

---

From: <[email-masked]>
Date: Thu, 12 Jun 2008 19:00:55 -0400

Thanks to all who answered my request/response question.  I have a couple 
more of SIP questions.

-1-
I've seen SIP calls where the callee's SDP is transmitted not through the 
usual 200 OK response but through other responses (like 183 Session 
Progress).  In fact, the callee starts sending/receiving RTP/RTCP streams 
long before he/she sends out the 200 OK response.  Is this legit?

-2-
Are RTP/RTCP streams associated with dialogs or with sessions?  In other 
words, assuming a SIP session with multiple dialogs, can each dialog have 
its own (private) set of RTP/RTCP streams?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 12 Jun 2008 16:10:35 -0700

> Sent: Thursday, June 12, 2008 4:01 PM
> To: [email-masked]
> Subject: [Sip] Questions regarding SDPs and dialogs...
> 

Yes, it's called "early media".  One of the better discussions of all sorts of
cases where this occurs is in
http://tools.ietf.org/html/draft-stucker-sipping-early-media-coping-03
(expired).

-d