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

From: "Siddhartha Bhakta" <[email-masked]>
Date: Fri, 10 Nov 2006 15:33:51 -0000

For forking, SIP UA shall send multiple INVITE with different branch
parameters. As s result, it shall receive response corresponding to
different INVITEs. Those shall create multiple dialogs. Here each of the
dialogs are having separate INVITE messages.

In this case (sec 2.9), multiple to-tags are received for a single INVITE
message. Therefore, these two cases are different.

SIP UA can easily create single dialog per INVITE message(with distinct
branch parameter). But managing multiple dialogs resulted due to single
INVITE seems weird.

Message: 6

Date: Fri, 10 Nov 2006 09:40:17 -0500

From: [email-masked]

Subject: Re: [Sipping] Query related to

      draft-ietf-sipping-service-examples-11

To: [email-masked]

Message-ID: <[email-masked]>

   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

---------------
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: Jeroen Van Bemmel <[email-masked]>
Date: Sat, 11 Nov 2006 12:13:50 +0100

There is another way around this: Since the 181 does not contain a Contact, the UAC can safely ignore it.

This does violate RFC3261 section 12.1.1, which says dialog creating responses MUST contain a Contact

Regards,
Jeroen

-----Oorspronkelijk bericht -----
Van: "Paul Kyzivat" <[email-masked]>
Aan: "Siddhartha Bhakta" <[email-masked]>
CC: [email-masked]
Verzonden: 10-11-06 20:04
Onderwerp: Re: [Sipping] Query related to draft-ietf-sipping-service-examples-11

The kind of change you describe is in fact a normative change. To get 
such a change made, you will have to explain why there is currently a 
problem that needs fixing. I don't think you have a case for that.

The bookkeeping to manage the multiple dialogs is currently already 
required for forking, so no added implementation is required. At worst 
it requires a little extra storage for state retention in some cases 
where the proposed change might avoid that.

Note that in case of forking it is necessary to retain early dialogs 
until a final response is received. If the final result is failure then 
the UA can immediately drop all the dialogs. If the result is success, 
then the other dialogs need to be retained long enough for any other 2xx 
responses in transit to arrive.

	Paul

Siddhartha Bhakta wrote:
> Thomas’s suggestion sounds good. If forking proxy needs to pass 18x 
> downstream, it should NOT put to-tag.
> 
> However, that shall put the restriction that PRACK can not be sent for 
> that 18x messages since PRACK can only be sent over established dialog. 
> If 18x response does not contain to-tag, it can not create dialog.
> 
>

---

From: Siddhartha Bhakta <[email-masked]>
Date: Sun, 12 Nov 2006 12:13:46 +0000 (GMT)

Dear paul,

The forking and virtual forking case are quite
different. In forking case, each of the dialogs are
managed separately. All these forked dialogs are
terminated properly. Either calling side cancels it or
called side reject it by sending 3xx-6xx responses.

For for virtual forking case, SIP entity creates
multiple dialogs by receiving multiple to-tags in
multiple 1xx responses. The management of those
dialogs seem peculiar to me.
  a)3xx-6xx of any such early dialog shall terminate
all these dialogs. Therefore, management of such
dialogs are not independent to each other.
  b)Only one of these dialogs is managed properly. I
have a question about the longevity about rest of the
dilaogs. Neither called side shall reject it nor
calling side shall cancel it. It least that's what is
seen in sec 2.9 of
draft-ietf-sipping-service-examples-11. In sec 2.9
call flow, the F5 creates a
dialog-ID1{Local-tag=1234567, remote-tag=3145678,
call-id=[email-masked]}. The F10 creates
another dialog-ID2{Local-tag=1234567,
remote-tag=9214d,
call-id=[email-masked]}. Subsequently,
F13 creates dialog-ID3{Local-tag=1234567,
remote-tag=765432,
call-id=[email-masked]}. The dialog-ID3
is being managed properly here. Neither Alice
canceling dialog-ID1 & dialog-ID2 nor Alice is getting
3xx-6xx for dialog-ID1 & dialog-ID2. What is the fate
of dialog-ID1 & dialog-ID2? Will they be timed-out?

The above two points clearly indicates that for
virtual forking case, only one dialog should be
created since only one of them are being managed
properly.
Hence the suggestion is to drop to-tag from 1xx
response for those cases. The first 2xx shall create
the dialog.

For forking case, I don't have any objection since
each of the dialogs is managed properly. In sec 2.9,
forking proxy creates dialog-ID1{Local-tag=1234567,
remote-tag=3145678,
call-id=[email-masked]} with User B1 and
creates dialog-ID2{Local-tag=1234567,
remote-tag=765432,
call-id=[email-masked]} with user B2.
This dialog-ID1 is cancelled by sending CANCEL(F6) and
dialog-ID2 is being continued. The dialog-ID2 is later
terminated by BYE(F19) message.

In summery, for virtual forking case, single dialog
should be created and managed. Therefore, forking
proxy should drop to-tag while passing 1xx response
downatream.
Or the alternative approach could be that, forking
proxy needs to send 3xx-6xx response for all early
dialogs those are not being continued. This way, for
dialogs shall be managed properly in virtual forking
case also.
Please comment.

>then the other dialogs need to be retained long
>enough for any other 
>2xx 

	Paul

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