Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-08-01 Thread Paul Kyzivat 

Robert,

I agree with most of what you say, but have a comment on one point:

On 8/1/17 12:23 PM, Robert Sparks wrote:
Be sure you are aware of (and implementing) the updates to RFC3261. You 
really need RFC6026 to answer this question cleanly.


At the top level, this is far enough into "things are violating 
protocol" that the specs aren't going to give algorithmic advice.


The closest they will get is that the transaction would pass the 200 to 
the transaction user (and then it would sit in the Accepted state until 
timer M fires so it can pass any _other_ 200s that show up with the same 
transaction identifier up to the TU - See figure 3 and the text above it 
in RFC6026).


Consider a case where the original INVITE was parallel forked. One of 
the forks behaves in this broken way and is the first to respond. Now 
the state machine is in the Accepted state. In that state 1xx and 
3xx-6xx responses are (IIUC) ignored. All *may* turn out if one of those 
other forks eventually returns a 2xx. Otherwise the call will just time 
out. Proper handling of the non-2xx final responses from the other forks 
won't occur. And if the 1xx was needed (e.g. for preconditions) then 
that won't work either.


Just dropping the broken 2xx would give better results. But I don't find 
any text that justifies doing that in this case.


Thanks,
Paul

Now, at the TU level, the 200 that shows up will not match any 
outstanding potential dialog (in some code-bases, you'll see these 
called proto-dialogs). The specs don't say this explicitly (as far as I 
recall anyhow), but the logic would follow something like this: "This 
doesn't match any INVITE _I've_ sent - it's an unsolicited response, I'm 
dropping it".


You might be tempted to try to ack on the 200, to at least stop the 
retransmissions (and maybe stop any media that might be flowing from the 
other end). If you do that, you could do whatever you do for any other 
unsolicited 200 that just shows up. But in this case, those attempts are 
likely to fail, and may make recovering from the mess worse, rather than 
better. Assuming you don't have a malicious actor, and what happened was 
that some B2BUAish thing changed the call-id in the request, but not the 
response, then the ACK you send (remember that 200-ACKs are sent with a 
new transaction identifier because they may take a different path than 
the INVITES) is likely to also get changed. If you send the ACK with the 
dialog identifiers from the INVITE, you _might_ get lucky and get the 
same transformation out of the thing in the middle, but given the 
different transaction ID, I suspect not. If you send the ACK with the 
dialog identifiers from the 200, they're almost certainly going to be 
changed before they get to the other side and the ACK won't be 
recognized. So letting the TU just drop the 200 is the safest thing to 
do in general.


Now, if you're in cohoots with the thing that's breaking the protocol, 
you know enough about its behavior to work around its brokenness, but 
then you're inventing some other protocol for a specific deployment and 
the specs can't help you.


RjS

On 8/1/17 11:03 AM, Paul Kyzivat wrote:

On 7/31/17 11:49 PM, Prakash K wrote:

Hi Paul,

Thanks a lot,  You have put it in a nice way , I understood the 
use-case for Forking


But I have the following question

*This all assumes that the 2xx matches an INVITE transaction you have 
pending, and that the from-tag and call-id match what was in the 
corresponding INVITE.Otherwise this is a stray message or an attack 
and ought to be ignored.*


*So if the 200 OK received having different "Call-ID" *not matching 
with the Call-ID which is sent in INVITE by UA, it should be ignored. 
( even if Cseq/From-tag/branch parameter is same as INVITE which is 
sent out)  ?*


What would be the UA behaviour in above case ?


This is an interesting case. 3261 doesn't provide a lot of explicit 
guidance - the proper action needs to be teased out of the text.


My first reaction was that you should just drop this message. But I 
couldn't find a good justification for that.


My next thought was that if it qualifies as a valid response to the 
*transaction* then the transaction should be run to completion. 
Following the revised state machine in rfc6026 that means moving to 
the Accepted state (if not already in that state), and passing the 2xx 
to the TU for further processing. Then the TU would discover that this 
response is messed up because it doesn't match an existing dialog, and 
also doesn't match a pending dialog (same from-tag and callid). As a 
result, it probably shouldn't send an ACK.


But this troubles me because it moves the state machine to the 
Accepted state. Thus is prevents subsequently received 1xx,3xx-6xx 
responses from being properly handled.


I think just dropping this response would lead to a better result, but 
I can't quite see how to justify that action from 3261 and 6026.


I'd like to hear from others wh

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-08-01 Thread Robert Sparks 
Be sure you are aware of (and implementing) the updates to RFC3261. You 
really need RFC6026 to answer this question cleanly.


At the top level, this is far enough into "things are violating 
protocol" that the specs aren't going to give algorithmic advice.


The closest they will get is that the transaction would pass the 200 to 
the transaction user (and then it would sit in the Accepted state until 
timer M fires so it can pass any _other_ 200s that show up with the same 
transaction identifier up to the TU - See figure 3 and the text above it 
in RFC6026).


Now, at the TU level, the 200 that shows up will not match any 
outstanding potential dialog (in some code-bases, you'll see these 
called proto-dialogs). The specs don't say this explicitly (as far as I 
recall anyhow), but the logic would follow something like this: "This 
doesn't match any INVITE _I've_ sent - it's an unsolicited response, I'm 
dropping it".


You might be tempted to try to ack on the 200, to at least stop the 
retransmissions (and maybe stop any media that might be flowing from the 
other end). If you do that, you could do whatever you do for any other 
unsolicited 200 that just shows up. But in this case, those attempts are 
likely to fail, and may make recovering from the mess worse, rather than 
better. Assuming you don't have a malicious actor, and what happened was 
that some B2BUAish thing changed the call-id in the request, but not the 
response, then the ACK you send (remember that 200-ACKs are sent with a 
new transaction identifier because they may take a different path than 
the INVITES) is likely to also get changed. If you send the ACK with the 
dialog identifiers from the INVITE, you _might_ get lucky and get the 
same transformation out of the thing in the middle, but given the 
different transaction ID, I suspect not. If you send the ACK with the 
dialog identifiers from the 200, they're almost certainly going to be 
changed before they get to the other side and the ACK won't be 
recognized. So letting the TU just drop the 200 is the safest thing to 
do in general.


Now, if you're in cohoots with the thing that's breaking the protocol, 
you know enough about its behavior to work around its brokenness, but 
then you're inventing some other protocol for a specific deployment and 
the specs can't help you.


RjS

On 8/1/17 11:03 AM, Paul Kyzivat wrote:

On 7/31/17 11:49 PM, Prakash K wrote:

Hi Paul,

Thanks a lot,  You have put it in a nice way , I understood the 
use-case for Forking


But I have the following question

*This all assumes that the 2xx matches an INVITE transaction you have 
pending, and that the from-tag and call-id match what was in the 
corresponding INVITE.Otherwise this is a stray message or an attack 
and ought to be ignored.*


*So if the 200 OK received having different "Call-ID" *not matching 
with the Call-ID which is sent in INVITE by UA, it should be ignored. 
( even if Cseq/From-tag/branch parameter is same as INVITE which is 
sent out)  ?*


What would be the UA behaviour in above case ?


This is an interesting case. 3261 doesn't provide a lot of explicit 
guidance - the proper action needs to be teased out of the text.


My first reaction was that you should just drop this message. But I 
couldn't find a good justification for that.


My next thought was that if it qualifies as a valid response to the 
*transaction* then the transaction should be run to completion. 
Following the revised state machine in rfc6026 that means moving to 
the Accepted state (if not already in that state), and passing the 2xx 
to the TU for further processing. Then the TU would discover that this 
response is messed up because it doesn't match an existing dialog, and 
also doesn't match a pending dialog (same from-tag and callid). As a 
result, it probably shouldn't send an ACK.


But this troubles me because it moves the state machine to the 
Accepted state. Thus is prevents subsequently received 1xx,3xx-6xx 
responses from being properly handled.


I think just dropping this response would lead to a better result, but 
I can't quite see how to justify that action from 3261 and 6026.


I'd like to hear from others who are knowledgeable about such things.

Thanks,
Paul


On 31 Jul 2017 10:21 p.m., "Paul Kyzivat" > wrote:


On 7/31/17 11:26 AM, Prakash K wrote:

What would be the behavior of UA when 200 OK received which is
not matching
the dialog

"200OK received by UA with different Call-id which is not in
context"


I see the following snippet in RFC 3261 which says UA should 
create

dialog. Wont this end up in acknowledging the hacking?

If the dialog identifier in the 2xx response matches the 
dialog

 identifier of an existing dialog, the dialog MUST be
transitioned to
 the "confirmed" state, and the route set for the dialog 
MUST be

 recomputed

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-08-01 Thread Paul Kyzivat 

On 7/31/17 11:49 PM, Prakash K wrote:

Hi Paul,

Thanks a lot,  You have put it in a nice way , I understood the use-case 
for Forking


But I have the following question

*This all assumes that the 2xx matches an INVITE transaction you have 
pending, and that the from-tag and call-id match what was in the 
corresponding INVITE.Otherwise this is a stray message or an attack and 
ought to be ignored.*


*So if the 200 OK received having different "Call-ID" *not matching with 
the Call-ID which is sent in INVITE by UA, it should be ignored. ( even 
if Cseq/From-tag/branch parameter is same as INVITE which is sent out)  ?*


What would be the UA behaviour in above case ?


This is an interesting case. 3261 doesn't provide a lot of explicit 
guidance - the proper action needs to be teased out of the text.


My first reaction was that you should just drop this message. But I 
couldn't find a good justification for that.


My next thought was that if it qualifies as a valid response to the 
*transaction* then the transaction should be run to completion. 
Following the revised state machine in rfc6026 that means moving to the 
Accepted state (if not already in that state), and passing the 2xx to 
the TU for further processing. Then the TU would discover that this 
response is messed up because it doesn't match an existing dialog, and 
also doesn't match a pending dialog (same from-tag and callid). As a 
result, it probably shouldn't send an ACK.


But this troubles me because it moves the state machine to the Accepted 
state. Thus is prevents subsequently received 1xx,3xx-6xx responses from 
being properly handled.


I think just dropping this response would lead to a better result, but I 
can't quite see how to justify that action from 3261 and 6026.


I'd like to hear from others who are knowledgeable about such things.

Thanks,
Paul


On 31 Jul 2017 10:21 p.m., "Paul Kyzivat" > wrote:


On 7/31/17 11:26 AM, Prakash K wrote:

What would be the behavior of UA when 200 OK received which is
not matching
the dialog

"200OK received by UA with different Call-id which is not in
context"


I see the following snippet in RFC 3261 which says UA should create
dialog. Wont this end up in acknowledging the hacking?

If the dialog identifier in the 2xx response matches the dialog
 identifier of an existing dialog, the dialog MUST be
transitioned to
 the "confirmed" state, and the route set for the dialog MUST be
 recomputed based on the 2xx response using the procedures
of Section
 12.2.1.2.  *Otherwise, a new dialog in the "confirmed"
state MUST be
 constructed using the procedures of Section 12.1.2.*


does this mean UA should generate ACK & immediately followed by
BYE should
be triggered?


As is mentioned in the prior paragraph, this is primarily about
forking. If the initial INVITE is forked, then two or more UASs may
respond. Each will choose a unique to-tag, and since the to-tag is
part of the dialog-id each will be associated with a distinct dialog.

The dialogs for various forks may be discovered via 1xx responses,
in which case the corresponding 2xx may match an existing dialog.
OTOH sometimes a UAS will send a 2xx without first sending a 1xx. In
that case the mentioned situation will occur.

Also note that this can happen without forking if the single UAS
immediately responds with a 2xx.

The forking case where you actually get multiple 2xx reponses,
establishing multiple dialogs, is pretty rare. Usually the forking
proxy ceases forking when it sees a 2xx response and attempts to
cancel any other outstanding legs. But it *can* happen and the UAC
needs to be prepared to cope when it does. *What* you do is
unspecified. Immediately sending a BYE is a popular solution because
it is easy. But it isn't especially friendly to the callee. Other
possibilities:

- form a conference call within your UAC, mixing the audio from
   the multiple legs

- play some prerecorded audio explaining why you are hanging up,
   then BYE.

This all assumes that the 2xx matches an INVITE transaction you have
pending, and that the from-tag and call-id match what was in the
corresponding INVITE. Otherwise this is a stray message or an attack
and ought to be ignored.

 Thanks,
 Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu

https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors




___
Sip-implementors mailing list
Sip-implementors@li

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-07-31 Thread Prakash K 
Hi Paul,

Thanks a lot,  You have put it in a nice way , I understood the use-case
for Forking

But I have the following question

*This all assumes that the 2xx matches an INVITE transaction you have
pending, and that the from-tag and call-id match what was in the
corresponding INVITE.Otherwise this is a stray message or an attack and
ought to be ignored.*

*So if the 200 OK received having different "Call-ID" *not matching with
the Call-ID which is sent in INVITE by UA, it should be ignored. ( even if
Cseq/From-tag/branch parameter is same as INVITE which is sent out)  ?*

What would be the UA behaviour in above case ?

On 31 Jul 2017 10:21 p.m., "Paul Kyzivat"  wrote:

> On 7/31/17 11:26 AM, Prakash K wrote:
>
>> What would be the behavior of UA when 200 OK received which is not
>> matching
>> the dialog
>>
>> "200OK received by UA with different Call-id which is not in context"
>>
>>
>> I see the following snippet in RFC 3261 which says UA should create
>> dialog. Wont this end up in acknowledging the hacking?
>>
>>If the dialog identifier in the 2xx response matches the dialog
>> identifier of an existing dialog, the dialog MUST be transitioned to
>> the "confirmed" state, and the route set for the dialog MUST be
>> recomputed based on the 2xx response using the procedures of Section
>> 12.2.1.2.  *Otherwise, a new dialog in the "confirmed" state MUST be
>> constructed using the procedures of Section 12.1.2.*
>>
>>
>> does this mean UA should generate ACK & immediately followed by BYE should
>> be triggered?
>>
>
> As is mentioned in the prior paragraph, this is primarily about forking.
> If the initial INVITE is forked, then two or more UASs may respond. Each
> will choose a unique to-tag, and since the to-tag is part of the dialog-id
> each will be associated with a distinct dialog.
>
> The dialogs for various forks may be discovered via 1xx responses, in
> which case the corresponding 2xx may match an existing dialog. OTOH
> sometimes a UAS will send a 2xx without first sending a 1xx. In that case
> the mentioned situation will occur.
>
> Also note that this can happen without forking if the single UAS
> immediately responds with a 2xx.
>
> The forking case where you actually get multiple 2xx reponses,
> establishing multiple dialogs, is pretty rare. Usually the forking proxy
> ceases forking when it sees a 2xx response and attempts to cancel any other
> outstanding legs. But it *can* happen and the UAC needs to be prepared to
> cope when it does. *What* you do is unspecified. Immediately sending a BYE
> is a popular solution because it is easy. But it isn't especially friendly
> to the callee. Other possibilities:
>
> - form a conference call within your UAC, mixing the audio from
>   the multiple legs
>
> - play some prerecorded audio explaining why you are hanging up,
>   then BYE.
>
> This all assumes that the 2xx matches an INVITE transaction you have
> pending, and that the from-tag and call-id match what was in the
> corresponding INVITE. Otherwise this is a stray message or an attack and
> ought to be ignored.
>
> Thanks,
> Paul
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-07-31 Thread Paul Kyzivat 

On 7/31/17 11:26 AM, Prakash K wrote:

What would be the behavior of UA when 200 OK received which is not matching
the dialog

"200OK received by UA with different Call-id which is not in context"


I see the following snippet in RFC 3261 which says UA should create
dialog. Wont this end up in acknowledging the hacking?

   If the dialog identifier in the 2xx response matches the dialog
identifier of an existing dialog, the dialog MUST be transitioned to
the "confirmed" state, and the route set for the dialog MUST be
recomputed based on the 2xx response using the procedures of Section
12.2.1.2.  *Otherwise, a new dialog in the "confirmed" state MUST be
constructed using the procedures of Section 12.1.2.*


does this mean UA should generate ACK & immediately followed by BYE should
be triggered?


As is mentioned in the prior paragraph, this is primarily about forking. 
If the initial INVITE is forked, then two or more UASs may respond. Each 
will choose a unique to-tag, and since the to-tag is part of the 
dialog-id each will be associated with a distinct dialog.


The dialogs for various forks may be discovered via 1xx responses, in 
which case the corresponding 2xx may match an existing dialog. OTOH 
sometimes a UAS will send a 2xx without first sending a 1xx. In that 
case the mentioned situation will occur.


Also note that this can happen without forking if the single UAS 
immediately responds with a 2xx.


The forking case where you actually get multiple 2xx reponses, 
establishing multiple dialogs, is pretty rare. Usually the forking proxy 
ceases forking when it sees a 2xx response and attempts to cancel any 
other outstanding legs. But it *can* happen and the UAC needs to be 
prepared to cope when it does. *What* you do is unspecified. Immediately 
sending a BYE is a popular solution because it is easy. But it isn't 
especially friendly to the callee. Other possibilities:


- form a conference call within your UAC, mixing the audio from
  the multiple legs

- play some prerecorded audio explaining why you are hanging up,
  then BYE.

This all assumes that the 2xx matches an INVITE transaction you have 
pending, and that the from-tag and call-id match what was in the 
corresponding INVITE. Otherwise this is a stray message or an attack and 
ought to be ignored.


Thanks,
Paul
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-07-31 Thread Rohit 
There is no response for a response. So no 481 will be there.

Rohit Jain 
Sent from my iPhone

> On 31-Jul-2017, at 9:31 PM, Prakash K  wrote:
> 
> How response will be sent for response ?
> 
> UA received 200 OK for INVITE which is sent out ,* but 200 OK received is
> with different call-id (wont match the context)*
> 
>> On 31 July 2017 at 21:07, Asim Sulaiman  wrote:
>> 
>> Dear Prakash,
>> 
>> I guess you will get 481 transaction does not exist.
>> 
>> 
>> Regards,
>> Asim Sulaiman
>> 
>> -Original Message-
>> From: sip-implementors-boun...@lists.cs.columbia.edu
>> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
>> Prakash
>> K
>> Sent: Monday, July 31, 2017 7:27 PM
>> To: sip-implementors@lists.cs.columbia.edu
>> Subject: [Sip-implementors] Processing of Standalone 200 OK response for
>> INVITE ["200OK received by UA with different Call-id which is not in
>> context"]
>> 
>> What would be the behavior of UA when 200 OK received which is not matching
>> the dialog
>> 
>> "200OK received by UA with different Call-id which is not in context"
>> 
>> 
>> I see the following snippet in RFC 3261 which says UA should create dialog.
>> Wont this end up in acknowledging the hacking?
>> 
>>  If the dialog identifier in the 2xx response matches the dialog
>>   identifier of an existing dialog, the dialog MUST be transitioned to
>>   the "confirmed" state, and the route set for the dialog MUST be
>>   recomputed based on the 2xx response using the procedures of Section
>>   12.2.1.2.  *Otherwise, a new dialog in the "confirmed" state MUST be
>>   constructed using the procedures of Section 12.1.2.*
>> 
>> 
>> does this mean UA should generate ACK & immediately followed by BYE should
>> be triggered?
>> 
>> 
>> --
>> Thanks
>> Prakash K
>> ___
>> Sip-implementors mailing list
>> Sip-implementors@lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>> 
>> 
>> 
>> 
>> Disclaimer :
>> This e-mail message may contain confidential, proprietary or legally
>> privileged information. It should not be used by anyone who is not the
>> original intended recipient. If you have erroneously received this message,
>> please delete it immediately and notify the sender. The recipient
>> acknowledges that EMIRCOM, as the case may be, are unable to exercise
>> control or ensure or guarantee the integrity of/over the contents of the
>> information contained in e-mail transmissions and further acknowledges that
>> any views expressed in this message are those of the individual sender and
>> no binding nature of the message shall be implied or assumed unless the
>> sender does so expressly with due authority of EMIRCOM. Before opening any
>> attachments please check them for viruses and defects.
>> 
>> 
>> 
>> 
>> Disclaimer :
>> This e-mail message may contain confidential, proprietary or legally
>> privileged information. It should not be used by anyone who is not the
>> original intended recipient. If you have erroneously received this message,
>> please delete it immediately and notify the sender. The recipient
>> acknowledges that EMIRCOM, as the case may be, are unable to exercise
>> control or ensure or guarantee the integrity of/over the contents of the
>> information contained in e-mail transmissions and further acknowledges that
>> any views expressed in this message are those of the individual sender and
>> no binding nature of the message shall be implied or assumed unless the
>> sender does so expressly with due authority of EMIRCOM. Before opening any
>> attachments please check them for viruses and defects.
>> 
>> 
> 
> 
> -- 
> Thanks
> Prakash K
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-07-31 Thread Prakash K 
How response will be sent for response ?

UA received 200 OK for INVITE which is sent out ,* but 200 OK received is
with different call-id (wont match the context)*

On 31 July 2017 at 21:07, Asim Sulaiman  wrote:

> Dear Prakash,
>
> I guess you will get 481 transaction does not exist.
>
>
> Regards,
> Asim Sulaiman
>
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
> Prakash
> K
> Sent: Monday, July 31, 2017 7:27 PM
> To: sip-implementors@lists.cs.columbia.edu
> Subject: [Sip-implementors] Processing of Standalone 200 OK response for
> INVITE ["200OK received by UA with different Call-id which is not in
> context"]
>
> What would be the behavior of UA when 200 OK received which is not matching
> the dialog
>
> "200OK received by UA with different Call-id which is not in context"
>
>
> I see the following snippet in RFC 3261 which says UA should create dialog.
> Wont this end up in acknowledging the hacking?
>
>   If the dialog identifier in the 2xx response matches the dialog
>identifier of an existing dialog, the dialog MUST be transitioned to
>the "confirmed" state, and the route set for the dialog MUST be
>recomputed based on the 2xx response using the procedures of Section
>12.2.1.2.  *Otherwise, a new dialog in the "confirmed" state MUST be
>constructed using the procedures of Section 12.1.2.*
>
>
> does this mean UA should generate ACK & immediately followed by BYE should
> be triggered?
>
>
> --
> Thanks
> Prakash K
> ___
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
> 
>
> Disclaimer :
> This e-mail message may contain confidential, proprietary or legally
> privileged information. It should not be used by anyone who is not the
> original intended recipient. If you have erroneously received this message,
> please delete it immediately and notify the sender. The recipient
> acknowledges that EMIRCOM, as the case may be, are unable to exercise
> control or ensure or guarantee the integrity of/over the contents of the
> information contained in e-mail transmissions and further acknowledges that
> any views expressed in this message are those of the individual sender and
> no binding nature of the message shall be implied or assumed unless the
> sender does so expressly with due authority of EMIRCOM. Before opening any
> attachments please check them for viruses and defects.
>
>
> 
>
> Disclaimer :
> This e-mail message may contain confidential, proprietary or legally
> privileged information. It should not be used by anyone who is not the
> original intended recipient. If you have erroneously received this message,
> please delete it immediately and notify the sender. The recipient
> acknowledges that EMIRCOM, as the case may be, are unable to exercise
> control or ensure or guarantee the integrity of/over the contents of the
> information contained in e-mail transmissions and further acknowledges that
> any views expressed in this message are those of the individual sender and
> no binding nature of the message shall be implied or assumed unless the
> sender does so expressly with due authority of EMIRCOM. Before opening any
> attachments please check them for viruses and defects.
>
>


-- 
Thanks
Prakash K
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Re: [Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-07-31 Thread Asim Sulaiman 
Dear Prakash,

I guess you will get 481 transaction does not exist.


Regards,
Asim Sulaiman

-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Prakash
K
Sent: Monday, July 31, 2017 7:27 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Processing of Standalone 200 OK response for
INVITE ["200OK received by UA with different Call-id which is not in
context"]

What would be the behavior of UA when 200 OK received which is not matching
the dialog

"200OK received by UA with different Call-id which is not in context"


I see the following snippet in RFC 3261 which says UA should create dialog.
Wont this end up in acknowledging the hacking?

  If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.  *Otherwise, a new dialog in the "confirmed" state MUST be
   constructed using the procedures of Section 12.1.2.*


does this mean UA should generate ACK & immediately followed by BYE should
be triggered?


--
Thanks
Prakash K
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors




Disclaimer :
This e-mail message may contain confidential, proprietary or legally
privileged information. It should not be used by anyone who is not the
original intended recipient. If you have erroneously received this message,
please delete it immediately and notify the sender. The recipient
acknowledges that EMIRCOM, as the case may be, are unable to exercise
control or ensure or guarantee the integrity of/over the contents of the
information contained in e-mail transmissions and further acknowledges that
any views expressed in this message are those of the individual sender and
no binding nature of the message shall be implied or assumed unless the
sender does so expressly with due authority of EMIRCOM. Before opening any
attachments please check them for viruses and defects.




Disclaimer :
This e-mail message may contain confidential, proprietary or legally privileged 
information. It should not be used by anyone who is not the original intended 
recipient. If you have erroneously received this message, please delete it 
immediately and notify the sender. The recipient acknowledges that EMIRCOM, as 
the case may be, are unable to exercise control or ensure or guarantee the 
integrity of/over the contents of the information contained in e-mail 
transmissions and further acknowledges that any views expressed in this message 
are those of the individual sender and no binding nature of the message shall 
be implied or assumed unless the sender does so expressly with due authority of 
EMIRCOM. Before opening any attachments please check them for viruses and 
defects.

___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

[Sip-implementors] Processing of Standalone 200 OK response for INVITE ["200OK received by UA with different Call-id which is not in context"]

2017-07-31 Thread Prakash K 
What would be the behavior of UA when 200 OK received which is not matching
the dialog

"200OK received by UA with different Call-id which is not in context"


I see the following snippet in RFC 3261 which says UA should create
dialog. Wont this end up in acknowledging the hacking?

  If the dialog identifier in the 2xx response matches the dialog
   identifier of an existing dialog, the dialog MUST be transitioned to
   the "confirmed" state, and the route set for the dialog MUST be
   recomputed based on the 2xx response using the procedures of Section
   12.2.1.2.  *Otherwise, a new dialog in the "confirmed" state MUST be
   constructed using the procedures of Section 12.1.2.*


does this mean UA should generate ACK & immediately followed by BYE should
be triggered?


-- 
Thanks
Prakash K
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors