Query on RFC 3578 v/s RFC 3261

[Sreerekha Shenoy (sresheno)]

Hi,

I was reading the RFC 3578 regarding ISUP overlap signaling to SIP.



In RFC 3578:

3.2. Generating Multiple INVITEs

...
If a SAM arrives to the gateway, T10 is refreshed and a new INVITE
with the new digits received is sent. The new INVITE has the same
Call-ID and the same From header field including the tag as the first
INVITE sent, but has an updated Request-URI.



[This section seems to indicate that the new INVITE happens without
awaiting the final response for the previous INVITE]





In RFC 3261:

14.1 UAC Behavior

...

Note that a UAC MUST NOT initiate a new INVITE transaction within a

dialog while another INVITE transaction is in progress in either

direction.



...



I find the two RFCs contradicting each other w.r.t INVITE initiated
before the previous INVITE transaction was over in case of RFC 3578.

Please let me know if I am wrong in my understanding.





Thanks,

Best Regards,

Rekha

[g***@zte.com.cn]

When UAC send two INVITE with the same from tag, it can recv two different
response with different to tag, and establishing two different dialog.

While in one dialog, there MUST be only one on-going INVITE transaction.

Cheers,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================

Post by Sreerekha Shenoy (sresheno)
Hi,
I was reading the RFC 3578 regarding ISUP overlap signaling to SIP.
3.2. Generating Multiple INVITEs
¡­
If a SAM arrives to the gateway, T10 is refreshed and a new INVITE
with the new digits received is sent. The new INVITE has the same
Call-ID and the same From header field including the tag as the first
INVITE sent, but has an updated Request-URI.
[This section seems to indicate that the new INVITE happens without
awaiting the final response for the previous INVITE]
14.1 UAC Behavior
¡­
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.
¡­
I find the two RFCs contradicting each other w.r.t INVITE initiated
before the previous INVITE transaction was over in case of RFC 3578.
Please let me know if I am wrong in my understanding.
Thanks,
Best Regards,
Rekha
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old

business.

Post by Sreerekha Shenoy (sresheno)
a SIP implementation.
SIP specifications.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Arunachala]

Hi,
I don't think are contradictory.

RFC 3261 is talking about an INVITE transaction within a dialog.
Since in the case of RFC 3578, there is NO dialog setup yet, as there
is NO response for the initial INVITE, RFC 3261 Section 14.1 does NOT
hold good here.

Regards,
Arun

On Tue, Mar 30, 2010 at 10:47 PM, Sreerekha Shenoy (sresheno)

Hi,
 I was reading the RFC 3578 regarding ISUP overlap signaling to SIP.
3.2.  Generating Multiple INVITEs
…
If a SAM arrives to the gateway, T10 is refreshed and a new INVITE
   with the new digits received is sent.  The new INVITE has the same
   Call-ID and the same From header field including the tag as the first
   INVITE sent, but has an updated Request-URI.
[This section seems to indicate that the new INVITE happens without awaiting
the final response for the previous INVITE]
14.1 UAC Behavior
…
  Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in either
   direction.
…
 I find the two RFCs contradicting each other w.r.t INVITE initiated before
the previous INVITE transaction was over in case of RFC 3578.
 Please let me know if I am wrong in my understanding.
Thanks,
Best Regards,
Rekha
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
implementation.
specifications.

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Sreerekha Shenoy (sresheno)]

Thanks Gao, Arun,

RFC 3261 says
"1. If there is an ongoing INVITE client transaction, the TU MUST
wait until the transaction reaches the completed or terminated
state before initiating the new INVITE."

RFC 3578 also mentions abt the first INVITE receiving a response (with a To Tag) [1xx/2xx/...]
The subsequent SAM still goes out with a new INVITE without this To-tag though.
So in essence, are we saying that we keep ignoring the dialog formation and still continue to do INVITEs until no more SAM's happen?

Arent we going against the "1" quoted above from 3261?


Thanks,
Best Regards,
Rekha



-----Original Message-----
From: Arunachala [mailto:***@gmail.com]
Sent: Wednesday, March 31, 2010 11:34 AM
To: Sreerekha Shenoy (sresheno)
Cc: ***@ietf.org
Subject: Re: [Sip] Query on RFC 3578 v/s RFC 3261

Hi,
I don't think are contradictory.

RFC 3261 is talking about an INVITE transaction within a dialog.
Since in the case of RFC 3578, there is NO dialog setup yet, as there
is NO response for the initial INVITE, RFC 3261 Section 14.1 does NOT
hold good here.

Regards,
Arun

On Tue, Mar 30, 2010 at 10:47 PM, Sreerekha Shenoy (sresheno)

Hi,
 I was reading the RFC 3578 regarding ISUP overlap signaling to SIP.
3.2.  Generating Multiple INVITEs
...
If a SAM arrives to the gateway, T10 is refreshed and a new INVITE
   with the new digits received is sent.  The new INVITE has the same
   Call-ID and the same From header field including the tag as the first
   INVITE sent, but has an updated Request-URI.
[This section seems to indicate that the new INVITE happens without awaiting
the final response for the previous INVITE]
14.1 UAC Behavior
...
  Note that a UAC MUST NOT initiate a new INVITE transaction within a
   dialog while another INVITE transaction is in progress in either
   direction.
...
 I find the two RFCs contradicting each other w.r.t INVITE initiated before
the previous INVITE transaction was over in case of RFC 3578.
 Please let me know if I am wrong in my understanding.
Thanks,
Best Regards,
Rekha
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[g***@zte.com.cn]

Ini-INVITE is always without to-tag which is decided by the UAS. I doesn't
see anything against with the "1" quoted above from 3261.

Or, please describe your use-case more detailed.

Cheers,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



"Sreerekha Shenoy (sresheno)" <***@cisco.com>
2010-03-31 16:27

ÊÕŒþÈË
"Arunachala" <***@gmail.com>, <***@zte.com.cn>, <***@ietf.org>
³­ËÍ

Ö÷Ìâ
RE: [Sip] Query on RFC 3578 v/s RFC 3261






Thanks Gao, Arun,

RFC 3261 says
"1. If there is an ongoing INVITE client transaction, the TU MUST
wait until the transaction reaches the completed or terminated
state before initiating the new INVITE."

RFC 3578 also mentions abt the first INVITE receiving a response (with a
To Tag) [1xx/2xx/...]
The subsequent SAM still goes out with a new INVITE without this To-tag
though.
So in essence, are we saying that we keep ignoring the dialog formation
and still continue to do INVITEs until no more SAM's happen?

Arent we going against the "1" quoted above from 3261?


Thanks,
Best Regards,
Rekha



-----Original Message-----
From: Arunachala [mailto:***@gmail.com]
Sent: Wednesday, March 31, 2010 11:34 AM
To: Sreerekha Shenoy (sresheno)
Cc: ***@ietf.org
Subject: Re: [Sip] Query on RFC 3578 v/s RFC 3261

Hi,
I don't think are contradictory.

RFC 3261 is talking about an INVITE transaction within a dialog.
Since in the case of RFC 3578, there is NO dialog setup yet, as there
is NO response for the initial INVITE, RFC 3261 Section 14.1 does NOT
hold good here.

Regards,
Arun

On Tue, Mar 30, 2010 at 10:47 PM, Sreerekha Shenoy (sresheno)

Post by Sreerekha Shenoy (sresheno)
Hi,
I was reading the RFC 3578 regarding ISUP overlap signaling to SIP.
3.2. Generating Multiple INVITEs
...
If a SAM arrives to the gateway, T10 is refreshed and a new INVITE
with the new digits received is sent. The new INVITE has the same
Call-ID and the same From header field including the tag as the first
INVITE sent, but has an updated Request-URI.
[This section seems to indicate that the new INVITE happens without awaiting
the final response for the previous INVITE]
14.1 UAC Behavior
...
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.
...
I find the two RFCs contradicting each other w.r.t INVITE initiated

before

Post by Sreerekha Shenoy (sresheno)
the previous INVITE transaction was over in case of RFC 3578.
Please let me know if I am wrong in my understanding.
Thanks,
Best Regards,
Rekha
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.

SIP

Post by Sreerekha Shenoy (sresheno)
implementation.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[Sreerekha Shenoy (sresheno)]

Hi Gao,

I currently don¡¯t have a use case to relate this RFC to.

However, I am trying to understand the written content of the two RFCs.



RFC 3261, section 14.1 ¡°1¡± mentions that a new INVITE client transaction is not supposed to start until the previous INVITE client transaction is completed.

In the overlap signaling (RFC 3578), we are creating a new INVITE client transaction (for SAM) when the old one is still in progress (for IAM)

Please let me know what is it that I am failing to understand here.



Thanks,

Best Regards,

Rekha







From: ***@zte.com.cn [mailto:***@zte.com.cn]
Sent: Wednesday, March 31, 2010 2:15 PM
To: Sreerekha Shenoy (sresheno)
Cc: Arunachala; ***@ietf.org
Subject: ŽðžŽ: RE: [Sip] Query on RFC 3578 v/s RFC 3261




Ini-INVITE is always without to-tag which is decided by the UAS. I doesn't see anything against with the "1" quoted above from 3261.

Or, please describe your use-case more detailed.

Cheers,

Gao

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================



"Sreerekha Shenoy (sresheno)" <***@cisco.com>

2010-03-31 16:27

ÊÕŒþÈË

"Arunachala" <***@gmail.com>, <***@zte.com.cn>, <***@ietf.org>

³­ËÍ


Ö÷Ìâ

RE: [Sip] Query on RFC 3578 v/s RFC 3261








Thanks Gao, Arun,

RFC 3261 says
"1. If there is an ongoing INVITE client transaction, the TU MUST
wait until the transaction reaches the completed or terminated
state before initiating the new INVITE."

RFC 3578 also mentions abt the first INVITE receiving a response (with a To Tag) [1xx/2xx/...]
The subsequent SAM still goes out with a new INVITE without this To-tag though.
So in essence, are we saying that we keep ignoring the dialog formation and still continue to do INVITEs until no more SAM's happen?

Arent we going against the "1" quoted above from 3261?


Thanks,
Best Regards,
Rekha



-----Original Message-----
From: Arunachala [mailto:***@gmail.com]
Sent: Wednesday, March 31, 2010 11:34 AM
To: Sreerekha Shenoy (sresheno)
Cc: ***@ietf.org
Subject: Re: [Sip] Query on RFC 3578 v/s RFC 3261

Hi,
I don't think are contradictory.

RFC 3261 is talking about an INVITE transaction within a dialog.
Since in the case of RFC 3578, there is NO dialog setup yet, as there
is NO response for the initial INVITE, RFC 3261 Section 14.1 does NOT
hold good here.

Regards,
Arun

On Tue, Mar 30, 2010 at 10:47 PM, Sreerekha Shenoy (sresheno)

Post by Sreerekha Shenoy (sresheno)
Hi,
I was reading the RFC 3578 regarding ISUP overlap signaling to SIP.
3.2. Generating Multiple INVITEs
...
If a SAM arrives to the gateway, T10 is refreshed and a new INVITE
with the new digits received is sent. The new INVITE has the same
Call-ID and the same From header field including the tag as the first
INVITE sent, but has an updated Request-URI.
[This section seems to indicate that the new INVITE happens without awaiting
the final response for the previous INVITE]
14.1 UAC Behavior
...
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.
...
I find the two RFCs contradicting each other w.r.t INVITE initiated before
the previous INVITE transaction was over in case of RFC 3578.
Please let me know if I am wrong in my understanding.
Thanks,
Best Regards,
Rekha
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

[g***@zte.com.cn]

please see inlines.

===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
e_mail : ***@zte.com.cn
===================================

Post by Sreerekha Shenoy (sresheno)
Hi Gao,
I currently don¡¯t have a use case to relate this RFC to.
However, I am trying to understand the written content of the two RFCs.
RFC 3261, section 14.1 ¡°1¡± mentions that a new INVITE client
transaction is not supposed to start until the previous INVITE
client transaction is completed.

It is in one dialog that there MUST be one INVITE transaction at one time
point.

Post by Sreerekha Shenoy (sresheno)
In the overlap signaling (RFC 3578), we are creating a new INVITE
client transaction (for SAM) when the old one is still in progress (for

IAM)

Post by Sreerekha Shenoy (sresheno)
Please let me know what is it that I am failing to understand here.

The different INVITE are(or would be) in different dialogs. And in one
specific dialog, there would be only one INVITE transaction at one time
point, as defined in RFC3261's above definition.

I hope the explanation is useful.

Cheers,

Gao

Post by Sreerekha Shenoy (sresheno)
Thanks,
Best Regards,
Rekha
Sent: Wednesday, March 31, 2010 2:15 PM
To: Sreerekha Shenoy (sresheno)
Subject: ŽðžŽ: RE: [Sip] Query on RFC 3578 v/s RFC 3261
Ini-INVITE is always without to-tag which is decided by the UAS. I
doesn't see anything against with the "1" quoted above from 3261.
Or, please describe your use-case more detailed.
Cheers,
Gao
===================================
Zip : 210012
Tel : 87211
Tel2 :([phone]
===================================
2010-03-31 16:27
ÊÕŒþÈË
³­ËÍ
Ö÷Ìâ
RE: [Sip] Query on RFC 3578 v/s RFC 3261
Thanks Gao, Arun,
RFC 3261 says
"1. If there is an ongoing INVITE client transaction, the TU MUST
wait until the transaction reaches the completed or terminated
state before initiating the new INVITE."
RFC 3578 also mentions abt the first INVITE receiving a response
(with a To Tag) [1xx/2xx/...]
The subsequent SAM still goes out with a new INVITE without this To-
tag though.
So in essence, are we saying that we keep ignoring the dialog
formation and still continue to do INVITEs until no more SAM's happen?
Arent we going against the "1" quoted above from 3261?
Thanks,
Best Regards,
Rekha
-----Original Message-----
Sent: Wednesday, March 31, 2010 11:34 AM
To: Sreerekha Shenoy (sresheno)
Subject: Re: [Sip] Query on RFC 3578 v/s RFC 3261
Hi,
I don't think are contradictory.
RFC 3261 is talking about an INVITE transaction within a dialog.
Since in the case of RFC 3578, there is NO dialog setup yet, as there
is NO response for the initial INVITE, RFC 3261 Section 14.1 does NOT
hold good here.
Regards,
Arun
On Tue, Mar 30, 2010 at 10:47 PM, Sreerekha Shenoy (sresheno)

Post by Sreerekha Shenoy (sresheno)
Hi,
I was reading the RFC 3578 regarding ISUP overlap signaling to SIP.
3.2. Generating Multiple INVITEs
...
If a SAM arrives to the gateway, T10 is refreshed and a new INVITE
with the new digits received is sent. The new INVITE has the same
Call-ID and the same From header field including the tag as the first
INVITE sent, but has an updated Request-URI.
[This section seems to indicate that the new INVITE happens without awaiting
the final response for the previous INVITE]
14.1 UAC Behavior
...
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.
...
I find the two RFCs contradicting each other w.r.t INVITE initiated before
the previous INVITE transaction was over in case of RFC 3578.
Please let me know if I am wrong in my understanding.
Thanks,
Best Regards,
Rekha
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.

SIP

Post by Sreerekha Shenoy (sresheno)

Post by Sreerekha Shenoy (sresheno)
implementation.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this
mail is solely property of the sender's organization. This mail
communication is confidential. Recipients named above are obligated
to maintain secrecy and are not permitted to disclose the contents
of this communication to others.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please
notify the originator of the message. Any views expressed in this
message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.