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

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

About point 3) I can say that not to-tag but Via
Branch parameter of SIP responses helps forking proxy
to associate those with any forked dialog. If 4xx-6xx
is received then depending on the via branch
parameter, forking proxy can know which dialog is
being terminated. The very first to-tag does not
really help forking proxy to associate with any
dialog. Therefore, I can not understand the reason of
extra ambiguity if to-tag of 1xx response is being
dropped.

Your point 2) and 3) ensures that Alice can manage
three dilaogs properly. If point 1) is implemented
then I can not understand how the dialogs created by
F5 and F10 shall be terminated at Alice in sec 2.9.
The dialog created by F13 is terminated by BYE(F18) as
far as Alice is concerned. I have asked this question
earlier also. I am yet to get answer from anyone!

Thanks and Regards,
Siddhartha

Brett Tate Wrote:
-----------------

I do not have a strong opinion concerning the sending
of 181 (without
SDP) when the proxy has received the 487 response. 
There are 3 options;
however only option 1 is compliant with rfc3261.

1) Follow service example and add new To tag.  This is
the only rfc3261
compliant solution.

2) Use the To tag of the received failure response. 
This is non
complaint to rfc3261 and requires waiting for the 487.
 The reason that
it might be nice is because allowing this to be valid
would easily allow
a new 1xx response code to be sent by a forking proxy
to indicate when a
particular early dialog no longer exists.  However
there are definitely
other ways to solve that problem.

3) Send non-100 1xx responses without To tag.  This
provides extra
ambiguity; and this is especially true when multiple
forking proxies are
involved.  And it is non compliant to rfc3261.

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

_______________________________________________
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: "Brett Tate" <[email-masked]>
Date: Mon, 13 Nov 2006 10:24:55 -0500

> About point 3) I can say that not to-tag but Via Branch 
> parameter of SIP responses helps forking proxy to associate 
> those with any forked dialog. If 4xx-6xx is received then 
> depending on the via branch parameter, forking proxy can know 
> which dialog is being terminated. The very first to-tag does 
> not really help forking proxy to associate with any dialog. 
> Therefore, I can not understand the reason of extra ambiguity 
> if to-tag of 1xx response is being dropped.

The ambiguity is not with the 18x's received at the forking proxy.  The
ambiguity is at the UA receiving the proxied 18x's which in your
proposal would not contain To tags.

> Your point 2) and 3) ensures that Alice can manage three 
> dilaogs properly. If point 1) is implemented then I can not 
> understand how the dialogs created by
> The dialog created by F13 is terminated by BYE(F18) as far as 
> Alice is concerned. I have asked this question earlier also. 
> I am yet to get answer from anyone!

The forking proxy terminates them per rfc3261 section 16.7 step 10.
Otherwise during race conditions or when the caller wants to release a
particular dialog, the caller can send a BYE for the individual dialog.

---

From: Siddhartha Bhakta <[email-masked]>
Date: Mon, 13 Nov 2006 17:38:28 +0000 (GMT)

My response is inserted below starting with [SB].

--- Brett Tate <[email-masked]> wrote:

> Branch 

[SB] If to-tag is dropped from 18x response, then
dialog creation shall be deferred. That's is exactly
what I am proposing in this case. Since forking proxy
does not know whether to this dialog shall be
continued or not, it should deferred the dialog
creation at the SIP entity behind.

> three 

[SB] I don't understand, how dialogs created by F5 and
F10 are terminated at Alice. Proxy is sending CANCEL
towards User B1 to terminated dialog created by F4 but
it is not sending anything back to Alice.

In fact, the proxy is not doing anything to terminate
the dialog created by F5 and F10 at Alice in sec 2.9.
Alice is also not sending CANCEL for those 
dialogs. Therefore, I can not understand, how those
dialog shall be terminated at Alice.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Nov 2006 13:05:26 -0500

Siddhartha Bhakta wrote:
> to associate those with any forked dialog.

I disagree. The branch parameter associates the response with a 
particular request.

It is the Call-ID, To-tag, and From-tag that identify a particular 
dialog. In the forking case, the To-tags are not initially known to the 
UAC. So the Call-ID and From-tag define a half-formed dialog, and each 
response with a unique To-tag defines a new dialog.

If you try to associate the half-formed dialog with the 
invite-transaction you may have trouble with some things. Of particular 
note, once you receive one 2xx response, you may have difficulty 
establishing added dialogs for other 2xx responses that might arrive.

There is even more difficulty in case of subscribe/notify. In that case, 
extra dialogs may be established based on received NOTIFY requests which 
aren't tied to the SUBSCRIBE by branch, only by callid and tags.

> If 4xx-6xx
> being terminated.

This happens to work because only a single non-successful final response 
is ever returned. Note that this implies the termination of *all* early 
dialogs that might have been established. (There may have been more than 
one.)

> The very first to-tag does not

The first to-tag received identifies the creation of the first early 
dialog. Subsequent responses with the same to-tag then must follow the 
offer/answer rules for that dialog.

Dropping the to-tag is wrong because a to-tag is required in a 1xx response.

> three dilaogs properly.

This is moot since these are illegal.

> If point 1) is implemented

Brett already gave a reference for how these get terminated.

	Paul

---

From: Siddhartha Bhakta <[email-masked]>
Date: Tue, 14 Nov 2006 17:31:59 +0000 (GMT)

> dialogs that might have been established. (There may

So far, I thought that each of the forked INVITE
transactions shall be managed independently. The 4xx
of one INVITE shall not affect other INVITE
transactions.
Atleast "2.12.  Single Line Extension" of
draft-ietf-sipping-service-examples-10.txt indicates
so.
After F8(480 Not Logged In) receiving also, Proxy was
continuing with the INVITE transaction with User B3.
It will be really surprising to me if you say that
call flow in 2.12 of Single Line Extension" of
draft-ietf-sipping-service-examples-10.txt is not as
per RFC3261. The reason is twofold. Firstly, this
draft is proposed(March, 2006) long after RFC3261.
Secondly, the forking proxes I came across do follow
the draft-ietf-sipping-service-examples-10.txt instead
of what you are saying.

If I accept your comment, then I can say parallel
forking is not possible. Or atleast, parallel forking
will not be safe. If any instance of a given user
returns 4xx-6xx then all other forked INVITE
transaction shall be terminated. Only sequencial
forking shall be possible. On receiving final error
response from one INVITE, the forking proxy can send
another forked INVITE. Not before that. This shall
impose time constraint to any SIP services based on
SIP forking. I can see that
draft-ietf-sipping-service-examples-11 does not
mention any parallel forking. All the forkings in this
draft are sequencial. The "Single Line Extension" is
also removed from this draft.

> aren't tied to the SUBSCRIBE by branch, only by

We came across following call flow from the
deployment,

Proxy       OUR-NODE        User2       User
  |            |            |            |
  | INVITE F1  |            |            |
  |----------->| INVITE F2  |            |
  |            |----------->|            |
  |            |  183 F3    |            |
  |   183 F4   |<-----------|            |
  |<-----------|            |            |
  Request Timesout          |            |
  |            |            |            |
  |  CANCEL F5 |            |            |
  |----------->|  CANCEL F6 |            |
  |            |----------->|            |
  | INVITE F7  |            |            |
  |----------->| INVITE F8  |            |
  |            |------------------------>|
  |            |    200 F9  |            |
  |    200 F10 |<-----------|            |
  |<-----------|            |            |
  |            |    487 F11 |            |
  |    487 F12 |<-----------|            |
  |<-----------|            |            |
  |   ACK F13  |            |            |
  |----------->|  ACK F14   |            |
  |            |----------->|            |
  |            |            |            |
  |            |  200 F15   |            |
  |    200 F16 |<------------------------|
  |<-----------|            |            |
  |   ACK F17  |            |            |
  |----------->|  ACK F18   |            |
  |            |------------------------>|
  |            |            |            |
  |            |            |            |

If OUR-NODE is RFC3261 compliant Proxy then it shall
terminate other early dialog (created by 180; not
shown) on receiving 487 F11. Therefore, the overlapped
forking as specified above shall be prevented by
OUR-NODE.

Only solution was to create separate half-formed
dialog for separate INVITE. This shall be done if we
consider the <Call-ID, From-tag, Branch> as the
half-formed dialog. As soon as to-tag shall be
received the dialog shall be created with <Call-ID,
From-tag, to-tag>. I believe, in RFC2543, branch
parameter was used to associate response with any
forked SIP Request.

For the above flow, OUR-NODE could have delayed the
2nd INVITE but this approach can not save us if
OUR-NODE is placed between Forking Proxy and Users in
"2.12 of Single Line Extension" call flow of
draft-ietf-sipping-service-examples-10.txt.

However, you have rightly pointed out the
SUBSCRIBE-NOTIFY case, where the above approach shall
definitely fail as NOTIFY may create dialog initiated
by SUBSCRIBE. I always feel the special handling for
SUBSCRIBE-NOTIFY was not really necessary. If so, then
why it is not written that UPDATE can create the
dialog initiated by INVITE message. Due to network
problem, UPDATE can also reach to Caller before first
1xx(non 100) response from Called party.

Thanks and Regards,
Siddhartha

---

From: Siddhartha Bhakta <[email-masked]>
Date: Tue, 14 Nov 2006 17:51:02 +0000 (GMT)

Brett/Paul,

In sec 2.9, if you consider Alice only then you can
see that 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]}.

Neither Alice is sending CANCEL for dialog-ID1 &
dialog-ID2, nor Proxy is sending 3xx-6xx to Alice for
dialog-ID1 & dialog-ID2.
How dialog-ID1 & dialog-ID2 shall be terminated at
Alice? You are possibly suggesting Alice to send BYE
on those dialog! But that is missing in sec 2.9.
Please comment.

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 14 Nov 2006 13:25:15 -0500

> Neither Alice is sending CANCEL for dialog-ID1 & dialog-ID2, 
> nor Proxy is sending 3xx-6xx to Alice for
> dialog-ID1 & dialog-ID2.
> How dialog-ID1 & dialog-ID2 shall be terminated at Alice? You 
> are possibly suggesting Alice to send BYE on those dialog! 
> But that is missing in sec 2.9.

If you look closer at rfc3261 (and rfc2543) basically only 1 final
response for the INVITE is proxied back to the caller.  Thus Alice can
assume that the other dialogs have been released upon receiving a final
response for the INVITE.  During race conditions extra INVITE 2xx
responses might be received on the other dialogs.  Only within these
race conditions does Alice need to send the extra BYEs.  And there is no
reason for Alice to send a CANCEL if a final response for the INVITE has
been received because the forking proxies sent or will send the CANCELs
as needed.

---

From: Siddhartha Bhakta <[email-masked]>
Date: Tue, 14 Nov 2006 18:36:00 +0000 (GMT)

Brett,

But forking proxy needs to send CANCEL for all early
dialogs after receiving final reasponse of one INVITE.
Why is the discrimination?
Is it due to the fact that forking proxy has to send
multiple INVITE and multiple dialogs are created due
to response of different INVITE dialogs whereas SIP-UA
behind Forking proxy creates multiple dialogs for a
single INVITE message?

--- Brett Tate <[email-masked]> wrote:

> dialog-ID2, 
> Alice? You

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Nov 2006 12:30:54 -0500

> behind Forking proxy creates multiple dialogs for a

You keep talking about the dialogs as if they matter to the proxy. They 
do not. Proxies can function quite properly without any awareness of them.

The proxy has one *transaction* with alice, and multiple *transactions* 
that it creates in order to do forking. The proxy is responsible for 
seeing that all of the transactions it initiated are completed. That is 
why *it* sends CANCEL to other transactions after it has a response it 
wants to send back. CANCEL is a request to terminate a *transaction* 
early, not a dialog.

In the case of a 2xx response, the hope is that the cancel will be 
successful and as a result there will only be one 2xx response. However 
there remains a race condition in that case. It was deemed to be better 
for the UAC to deal with this case, so the proxy is expected to forward 
all the 2xx responses, and for the UAC to deal with them.

This is recognized as an ugly case. May people wish forking had never 
been included, but it is, so we must deal with it.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 16 Nov 2006 12:19:39 -0500

Comments inline.

	Paul

> of one INVITE shall not affect other INVITE

Yes and no. The transactions transactions that the proxy initiates 
complete independently. But a forking proxy may only return one non-2xx 
final response. It can try other alternatives after receiving a non-2xx 
final response as long is it doesn't return one to the caller. 
Eventually it must decide which of the final responses to send upstream. 
When it does this it needs to cancel all the other other forks.

OTOH, the proxy must return all 2xx responses it receives.

So, if it has receives a non-2xx final response, and wishes to give up, 
it must cancel all outstanding forked requests and wait for them to 
complete, and then pick one of the final responses to send. If it 
receives a 2xx response, it is to send a cancel to all remaining 
branches, locally handle any non-2xx final responses, and forward all 
2xx final responses.

So, while each transaction the proxy initiates as a result of forking 
completes independently, but the proxy is forced to coordinate they way 
it manages them in order to follow proxy rules, and in order to send the 
proper responses to the invite transaction that it received.

Also, while a forking proxy must be transaction stateful, it need not 
have any knowledge of the resulting dialog(s).

> draft-ietf-sipping-service-examples-10.txt indicates

I wouldn't use that as an authoritative source. There is a new -11 
version that doesn't even include the example you reference.

> continuing with the INVITE transaction with User B3.

The *proxy* can continue. It knows about all the forks. But the UAC is 
unaware of this. The UAC can infer that forking is going on when it 
receives responses containing different to-tags.

> the draft-ietf-sipping-service-examples-10.txt instead

I just glanced at it, and without studying carefully, it does seem to be 
ok. (I don't know why it was removed in version -11.)

But it seems to be properly returning to-tags. F7 and F11 both extablish 
early dialogs. F12 converts one of them into a final dialog. It is then 
up to the UAC to make the early dialog established by F7 go away. It 
should keep it around for a time in case a 200 comes in for it, but 
eventually if that doesn't happen it must discard it.

> transaction shall be terminated.

You and I probably aren't talking about the same thing. The situation id 
different at the UAC than it is at the proxy.

> Only sequencial

The UAC can't see any difference between serial and parallel forking, 
except that it might result in getting more than one 2xx response.

Parallel forking is definitely permitted and can work.

> shown) on receiving 487 F11.

I'm guessing you mean a 180 in response to F8, right?

F1 and F7 are entirely independent. If OUR-NODE is a *proxy*, then when 
it receives F11, it should cancel any remaining transactions it 
established as a result of F1. In this case there aren't any. The 
transactions resulting from F7 are unaffected by this.

Note that this has nothing to do with dialogs.

The story is potentially different if OUR-NODE is a B2BUA, and there are 
few rules about how to get that right, except that it must act as a UA 
on both sides. If you are trying to have it be a B2BUA and yet appear to 
alice as a proxy, then it gets tricky indeed.

> Therefore, the overlapped

If 3261 is followed there should be no problem here.

> parameter was used to associate response with any

I don't have the time to go research again what 2543 called for here.

> 1xx(non 100) response from Called party.

Usually UPDATE is used in conjunction with 100rel. In that case, the 1xx 
will be confirmed by a PRACK before an UPDATE is sent. I see there is a 
potential issue if the 1xx isn't reliable and then an UPDATE is sent. In 
most cases I think the offer/answer rules will make this usage illegal.

I suppose you could raise this as another issue for the Race Conditions 
draft to address if you think it important.