Subject: [Sipping] Query related to draft-ietf-sipping-service-examples-11

From: "Siddhartha Bhakta" <[email-masked]>
Date: Thu, 9 Nov 2006 17:21:26 -0000

Dear Alan/Robert/Kevin,
 
I could find out following problem in sec 2.9 as far
as SIP dialog is concerned. The F5(180) is creating an
early dialog between Alice and Proxy(from-tag=1234567, to-tag=3145678).
Whereas, later on, Proxy is sending back 181(F10) and 180(F13) with a
different to-tag. The F10 (181) contains to-tag=9214d and to-tag=765432
 
Is it not the violation of RFC3261 dialog concept?
I am not sure how the Alice SIP entity shall manage the SIP dialog.
Definitely, F10 and F13 shall not be associated to the dialog created by F5.
Alice might discard F10 (181) as that is containing different to-tags. The
out of dialog 1xx should be discarded.
 
Similar problem is there in sec 2.12. The F5 and F18 contains different
to-tags.
In sec 2.7, the F3 and F6 have different to-tags.
In sec 2.8, F6 and F9 have different to-tags.
 
Early response is anticipated.
 
Thanks,

Siddhartha

---------------
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden.
---------------

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

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Nov 2006 13:02:35 -0500

> Is it not the violation of RFC3261 dialog concept?

No. This is normal behavior in the presence of forking.

Each distinct to-tag results in a new early dialog.

> Alice might discard F10 (181) as that is containing different to-tags.

Alice must recognize that she is receiving responses for two dialogs, 
and must be prepared for either of them to receive a 200. Discarding the 
responses for the 2nd dialog is incorrect.

Normally you will receive a final response for one of the early dialogs, 
or possibly for yet another dialog that hasn't previously been seen. If 
that is >=300, they you should consider all of your dialogs terminated.

If you get a 2xx response, then you know one dialog that succeeded. 
Usually all the others will be canceled by the proxy. But it is possible 
that there is another 2xx on the way for another dialog. If so then you 
must deal with that some way. Most commonly people send a BYE to any 
subsequent 2xxs they receive.

	Paul

> The out of dialog 1xx should be discarded.
> 
> Similar problem is there in sec 2.12. The F5 and F18 contains different to-tags.

---

From: Siddhartha Bhakta <[email-masked]>
Date: Thu, 9 Nov 2006 21:19:53 +0000 (GMT)

Dear Paul,

I could not appreciate the comment "Each distinct
to-tag results in a new early dialog". May be due to
lack of my understanding about the dialog concept.

I am considering Alice in isolation here.

In sec 2.9 call flow, the F5 creates a
dialog-ID1{Local-tag=1234567, remote-tag=3145678,
call-id=[email-masked]}. 
The F10 shall create another
dialog-ID2{Local-tag=1234567, remote-tag=9214d,
call-id=[email-masked]}. Subsequently,
F13 shall create dialog-ID3{Local-tag=1234567,
remote-tag=765432,
call-id=[email-masked]}.

In this call flow, the dialog-ID3 is being continued.
How dialog-ID1 and dialog-ID2 shall be terminated?
Will those be timed-out (32*T1)?
I suppose, the F18, F21 shall terminate dialog-ID3
only.

Moreover, the sec 13.3.1.1 of RFC3261 indicates that
"A UAS MAY send as many provisional responses as it
likes.  Each of these MUST indicate the same dialog
ID."

Initially I was assuming this logic. You can validate
this:
The dialog-id is being modified on receiving F10. It
is further modified on receiving F13. In this logic,
Alice shall not receive message related to dialog-ID1
after receiving F10. Similarly, Alice shall not
receive message related to dialog-ID2 after receiving
F13. Please clarify.
I was assuming the logic that, any early dialog
identifier can be modified. Though, I could not find
out such a logic in any RFC.

The sec 2.9 call flow also violates SDP offer/answer
flow mentioned in RFC3261. As per sec 13.2.1 of
RFC3261, if provisional response contains SDP answer,
then subsequent provisional response or 2xx response
should contain same SDP. If they contain different SDP
then UAC should ignore it. With this logic, SDP of F13
shall be ignored as Alice has already received SDP on
F5. This shall lead to the fact, Alice is not hearing
the ringtone fed by User B2.
Please comment.

In am quoting the relevent part(sec 13.2.1) of
RFC3261...

"      o  If the initial offer is in an INVITE, the
answer MUST be in a
         reliable non-failure message from UAS back to
UAC which is
         correlated to that INVITE.  For this
specification, that is
         only the final 2xx response to that INVITE. 
That same exact
         answer MAY also be placed in any provisional
responses sent
         prior to the answer.  The UAC MUST treat the
first session
         description it receives as the answer, and
MUST ignore any
         session descriptions in subsequent responses
to the initial
         INVITE."

> > Early response is anticipated.

__________________________________________________________
Yahoo! India Answers: Share what you know. Learn something new
http://in.answers.yahoo.com/

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 9 Nov 2006 22:46:31 +0100

181 is one of those types of responses for which I tend to think: wouldn't 
that work better without a to-tag?

I know the current RFC3261 rules don't allow that (non-100 responses MUST 
have a to-tag), and section 16.7 point 6 explicitly talks about a "virtual 
UAS" to model the case of a proxy sending a non-100 response. But OTOH: the 
proxy knows it won't be needing the dialog

Regards,
Jeroen

Paul Kyzivat wrote:
>> early dialog between Alice and Proxy(from-tag=1234567,
>> to-tag=3145678). Whereas, later on, Proxy is sending back 181(F10)
>> and 180(F13) with a different to-tag. The F10 (181) contains to-tag=9214d 
>> and
>> to-tag=765432 Is it not the violation of RFC3261 dialog concept?
>
>> Definitely, F10 and F13 shall not be associated to the dialog
>> created by F5. Alice might discard F10 (181) as that is containing
>> different to-tags.
>
> and must be prepared for either of them to receive a 200. Discarding
> the responses for the 2nd dialog is incorrect.
>
> Normally you will receive a final response for one of the early
> dialogs, or possibly for yet another dialog that hasn't previously
> been seen. If that is >=300, they you should consider all of your
> dialogs terminated.
> Usually all the others will be canceled by the proxy. But it is
> possible that there is another 2xx on the way for another dialog. If
> so then you must deal with that some way. Most commonly people send a
> BYE to any subsequent 2xxs they receive.
>
> Paul
>
>> Similar problem is there in sec 2.12. The F5 and F18 contains
>> different to-tags. In sec 2.7, the F3 and F6 have different to-tags.

---

From: [email-masked]
Date: Thu, 9 Nov 2006 23:38:12 -0500

From: "Jeroen van Bemmel" <[email-masked]>

You don't want to put an exception in the lower-layer processing of
Special Case Foo because the higher-layer won't be needing the
information.  That way lies madness.

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 10 Nov 2006 07:41:22 +0100

There is no need to change anything in the lower layers (I presume you mean 
transaction layer and below). The change would be that a proxy be allowed to 
originate 1xx responses without a to-tag, on the UAC side the dialog layer 
would recognise (as it already should) that there is no to-tag, hence no 
early dialog.

In any case, the current 2.9 example flow is wrong and incomplete: the way 
it currently is (with to-tag) F10 should have a Contact header, and the UAC 
should send BYE to this Contact

Regards,
Jeroen

[email-masked] wrote:
>   181 is one of those types of responses for which I tend to think:
>   wouldn't that work better without a to-tag?
>
>   I know the current RFC3261 rules don't allow that (non-100
>   responses MUST have a to-tag), and section 16.7 point 6 explicitly
>   talks about a "virtual UAS" to model the case of a proxy sending a
>   non-100 response. But OTOH: the proxy knows it won't be needing the
> dialog
>

---

From: "Siddhartha Bhakta" <[email-masked]>
Date: Fri, 10 Nov 2006 11:00:27 -0000

Jeroen,

I tend to agree with you on 181 responses. The 181 response should be
considered like 100 responses, which may not have to-tag. In fact, I think
100 and 181 MUST not have to-tag as those are not typically generated by
ultimate SIP endpoint.
In fact, the draft-ietf-sipping-service-examples-08 does not have to-tag in
181 responses.

Regards,
Siddhartha

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: 09 November 2006 21:47
To: Paul Kyzivat; Siddhartha Bhakta
Cc: [email-masked]
Subject: Re: [Sipping] Query related to
draft-ietf-sipping-service-examples-11

Regards,
Jeroen

---------------

---

From: [email-masked]
Date: Fri, 10 Nov 2006 14:59:31 +0100

> wouldn't that work better without a to-tag?
I agree with that point, it is particularly tricky for UAs 
implementations to receive a first 1xx with a toTag, and then, and 200 
OK with another one...
I general, they report a bug to proxy implementor ;-) and after 
realizing it is the "virtual UAS" case in RFC, they start to classify 
this as "evil" feature...
That's true that UAs should support forking, and thus, be capable of 
receiving multiple toTag, but is just not very often supported from my 
experience...
>
> I know the current RFC3261 rules don't allow that (non-100 responses 
> MUST have a to-tag), and section 16.7 point 6 explicitly talks about a 
> "virtual UAS" to model the case of a proxy sending a non-100 response. 
> But OTOH: the proxy knows it won't be needing the dialog
>
> Regards,
> Jeroen
>
> Paul Kyzivat wrote:
>> Siddhartha Bhakta wrote:
>>> Dear Alan/Robert/Kevin,
>>>
>>> and 180(F13) with a different to-tag. The F10 (181) contains 
>>> to-tag=9214d and

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 10 Nov 2006 09:28:13 -0500

> > 181 is one of those types of responses for which 
> > I tend to think: wouldn't that work better without 
> > a to-tag?
> 
> implementations to receive a first 1xx with a toTag, and 
> then, and 200 OK with another one...
> I general, they report a bug to proxy implementor ;-) and 
> after realizing it is the "virtual UAS" case in RFC, they 
> start to classify this as "evil" feature...
> That's true that UAs should support forking, and thus, be 
> capable of receiving multiple toTag, but is just not very 
> often supported from my experience...

User Agents expecting offer/answer compliance must support forking
proxies and thus 18x's and 2xx's with different To tags.

I discuss some of the reasons within the following link.

https://lists.cs.columbia.edu/pipermail/sip-implementors/2006-November/0
14620.html

---

From: [email-masked]
Date: Fri, 10 Nov 2006 09:40:17 -0500

From: [email-masked]

   I agree with that point, it is particularly tricky for UAs
   implementations to receive a first 1xx with a toTag, and then, and
   200 OK with another one...

How could a UA support forking generally and not handle this case
smoothly?

Forking of a request is not a weird special case.  Non-forking of a
request is the special case.

Dale

---

From: "Siddhartha Bhakta" <[email-masked]>
Date: Fri, 10 Nov 2006 14:56:48 -0000

If any SIP Proxy wants to generate any response when dialog is not created
properly(i.e., t-tag is not exchanged) then proxy should skip to-tag. This
logic shall avoid the mess.
The "100 Trying" would come in such a category. The "181 Call Is Being
Forwarded" message of draft-ietf-sipping-service-examples-11 draft should
not have to-tag.
If any SIP proxy wants to generate 183 of its own to feed some tone, it
should also skip to-tag.

With the above mentioned logic, we can not always avoid the fact that SIP UA
may receive multiple responses with different to-tags. Consider the CFNA
(sec 2.9 of draft-ietf-sipping-service-examples-11) where forking proxy
ought to send 180 (from User B1) downstream as proxy has no idea beforehand
whether User B1 shall pick up the phone or not.

Now the question is: If any SIP UA(Alice here) receives multiple
provisional/final responses (of single INVITE) with different to-tags then
whether it should create different dialogs or not?
I would suggest that SIP UA should not create separate dialog. Rather it
should modify the dialog-id of the existing dialog, if already created. As
soon as a response with different tag is received then earlier dialog
becomes invalid. Then what is point in keeping the earlier dialog !
This logic shall introduce the new concept that if provisional response is
received with to-tag when there is already an established dialog then it
shall modify the dialog-id. This shall ensure that if any SIP entity sends
single INVITE message then it shall create single dialog only.

Forking works on different principal: SIP entity sends multiple INVITEs
(with different branch parameters) and each of these INVITE shall create one
dialog once corresponding response shall be received with to-tag. But we are
talking about responses of a single INVITE !

Please suggest.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 10 November 2006 14:00
To: Jeroen van Bemmel
Cc: Paul Kyzivat; Siddhartha Bhakta; [email-masked]
Subject: Re: [Sipping] Query related to

---------------

---

From: [email-masked]
Date: Fri, 10 Nov 2006 16:30:55 +0100

> How could a UA support forking generally and not handle this case
Theoritically, you are right :-), in practice, after 5 SIPIT, forking is 
not always so well supported by UAs (and proxies, by the way), probably 
because
this is complex to implement... I still think that a proxy "muted 
temporarily" to a UAS is something unecesssary complex, it could be 
possible to say that a proxy sending
1xx reponses should NOT put any totag, (as for 100 trying)... So easy to 
say, so easy to implement...

Best regards,
Thomas