Sip Implementors

santosh.kalsangrah | 11 Jul 2012 08:40

UAC handling of 491 response to re-INVITE

Hi All,

Per section 14.1 (UAC Behavior) of RFC 3261, upon receiving 491 response to a re-INVITE, UAC should start a
timer with different values. Value of this timer is determined based on the Call-Id owner.

Here I got 2 questions:

1.       Why do we need to have different values of this timer?

2.       Do we have SIP way of identifying owner of Call-ID?

Thanks in advance,
Santosh Kalsangrah

Please do not print this email unless it is absolutely necessary. 

The information contained in this electronic message and any attachments to this message are intended for
the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged
information. If you are not the intended recipient, you should not disseminate, distribute or copy this
e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. 

WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any
attachments for the presence of viruses. The company accepts no liability for any damage caused by any
virus transmitted by this email. 

www.wipro.com

Mangal2 Singh | 11 Jul 2012 09:46

Re: UAC handling of 491 response to re-INVITE

Hi Santosh,

491 response for re-INVITE is sent when a request is already pending with the UAC. Different values of timer
are required so as to prevent the race condition so that UAC and UAS do not keep sending re-INVITE to each
other again & again. The owner of call id is the person who initiates a call i.e. sends initial INVITE
request. For more details on this, you can refer to section 3.3.1 of RFC 5407.

Consider the following scenario:
Alice                         Bob
     |                            |
     |         INVITE F1          |
     |--------------------------->|
     |      180 Ringing F2        |
     |<---------------------------|
     |          200 OK F3         |
     |<---------------------------|
     |           ACK F4           |
     |--------------------------->|
     |     Both Way RTP Media     |
     |<==========================>|
     |                            |
     |re-INVITE F5   re-INVITE F6 |
     |------------   -------------|
     |            \ /             |
     |             X              |
     |            / \             |
     |<-----------   ------------>|
     |   491 F8        491 F7     |
     |------------   -------------|
     |            \ /             |

(Continue reading)

Worley, Dale R (Dale | 11 Jul 2012 16:24

Re: UAC handling of 491 response to re-INVITE

On Wed, 2012-07-11 at 06:40 +0000, santosh.kalsangrah <at> wipro.com wrote:
> Per section 14.1 (UAC Behavior) of RFC 3261, upon receiving 491
> response to a re-INVITE, UAC should start a timer with different
> values. Value of this timer is determined based on the Call-Id owner.
> 
> 1.       Why do we need to have different values of this timer?

Since the 491 response is due to a glare condition (both UAs send
re-INVITEs to each other at the same time), if they both waited the same
length of time before sending another re-INVITE, they would likely send
the second re-INVITEs at the same time, thus causing both of them to
respond 491, etc.  By specifying different timers for each end, the
re-INVITE of the UA with the shorter timer will likely succeed.

> 2.       Do we have SIP way of identifying owner of Call-ID?

No.  The UAs have to remember which UA initiated the call.

Dale

Vivek Singla | 13 Jul 2012 17:58

Picon

Duplicate diversion headers in Invite

 
Hi,
 
I am trying to figure out a scenario in which a SIP proxy will get 2 very same Diversion headers. 
 
For example:
  Diversion: <sip:+1123456789 <at> 1.1.1.1;user=phone>; privacy=off; reason=unconditional; counter=1
  Diversion: <sip:+1123456789 <at> 1.1.1.1;user=phone>; privacy=off; reason=unconditional; counter=1

These 2 headers come in the same INvite message. 

I am just trying to see if there is a RFC out there to justify this duplication of these 2 headers?

Vivek.

Brett Tate | 13 Jul 2012 18:29

Re: Duplicate diversion headers in Invite

RFC 5086 is the historic RFC for diversion.  As far as I know, it does not forbid it.

The typical reason that you might see it involves looping.  A loop occurred and the device either handled it
differently or has not yet detected the loop (or reached Max-Forwards 0).

> -----Original Message-----
> From: sip-implementors-bounces <at> lists.cs.columbia.edu [mailto:sip-
> implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Vivek Singla
> Sent: Friday, July 13, 2012 11:58 AM
> To: Sip-implementors <at> lists.cs.columbia.edu
> Subject: [Sip-implementors] Duplicate diversion headers in Invite
> 
> 
> Hi,
> 
> I am trying to figure out a scenario in which a SIP proxy will get 2
> very same Diversion headers.
> 
> For example:
>   Diversion: <sip:+1123456789 <at> 1.1.1.1;user=phone>; privacy=off;
> reason=unconditional; counter=1
>   Diversion: <sip:+1123456789 <at> 1.1.1.1;user=phone>; privacy=off;
> reason=unconditional; counter=1
> 
> These 2 headers come in the same INvite message.
> 
> I am just trying to see if there is a RFC out there to justify this
> duplication of these 2 headers?
> 
> Vivek.

(Continue reading)

Brett Tate | 13 Jul 2012 18:31

Re: Duplicate diversion headers in Invite

Sorry for the resend, fixed RFC number.

> -----Original Message-----
> From: sip-implementors-bounces <at> lists.cs.columbia.edu [mailto:sip-
> implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Brett Tate
> Sent: Friday, July 13, 2012 12:29 PM
> To: Vivek Singla; Sip-implementors <at> lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Duplicate diversion headers in Invite
> 
> RFC 5806 is the historic RFC for diversion.  As far as I know, it does
> not forbid it.
> 
> The typical reason that you might see it involves looping.  A loop
> occurred and the device either handled it differently or has not yet
> detected the loop (or reached Max-Forwards 0).
> 
> > -----Original Message-----
> > From: sip-implementors-bounces <at> lists.cs.columbia.edu [mailto:sip-
> > implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Vivek Singla
> > Sent: Friday, July 13, 2012 11:58 AM
> > To: Sip-implementors <at> lists.cs.columbia.edu
> > Subject: [Sip-implementors] Duplicate diversion headers in Invite
> >
> >
> > Hi,
> >
> > I am trying to figure out a scenario in which a SIP proxy will get 2
> > very same Diversion headers.
> >
> > For example:

(Continue reading)

Vivek Singla | 13 Jul 2012 20:52

Picon

Re: Duplicate diversion headers in Invite

Thanks Brett for the corrected number. So I was looking into this rfc, I didn't see any error conditions
mentioning a duplicate diversion header. 
I am forgetting, but SIP has its own way of stopping the loops and looping messages, isnt it?
I am trying to think of any header or a parameter which SIP client or server look for in case of a loop. 
I mean what if there are more than 2 duplicated entries in Diversion headers. 

 Vivek.

From: Brett Tate <brett <at> broadsoft.com>
To: Vivek Singla <vivsingla <at> yahoo.com>; "Sip-implementors <at> lists.cs.columbia.edu"
<Sip-implementors <at> lists.cs.columbia.edu> 
Sent: Friday, July 13, 2012 11:31 AM
Subject: RE: [Sip-implementors] Duplicate diversion headers in Invite

Sorry for the resend, fixed RFC number.

> -----Original Message-----
> From: sip-implementors-bounces <at> lists.cs.columbia.edu [mailto:sip-
> implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Brett Tate
> Sent: Friday, July 13, 2012 12:29 PM
> To: Vivek Singla; Sip-implementors <at> lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] Duplicate diversion headers in Invite
> 
> RFC 5806 is the historic RFC for diversion.  As far as I know, it does
> not forbid it.
> 
> The typical reason that you might see it involves looping.  A loop
> occurred and the device either handled it differently or has not yet
> detected the loop (or reached Max-Forwards 0).
>

(Continue reading)

Brez Borland | 14 Jul 2012 11:35

Picon

Re: Duplicate diversion headers in Invite

Hi Vivek, inline

On Fri, Jul 13, 2012 at 7:52 PM, Vivek Singla <vivsingla <at> yahoo.com> wrote:

> Thanks Brett for the corrected number. So I was looking into this rfc, I
> didn't see any error conditions mentioning a duplicate diversion header.
> I am forgetting, but SIP has its own way of stopping the loops and looping
> messages, isnt it?
> I am trying to think of any header or a parameter which SIP client or
> server look for in case of a loop.
> I mean what if there are more than 2 duplicated entries in Diversion
> headers.
>

Looking through the RFC5806 it doesn't mention that Diversion header can be
used more than once neither. As I understand it implies redirection, and
explicitly specifies the destination party (single/one), therefore
duplication is not reasonable.

>
>  Vivek.
>
>
> From: Brett Tate <brett <at> broadsoft.com>
> To: Vivek Singla <vivsingla <at> yahoo.com>; "
> Sip-implementors <at> lists.cs.columbia.edu" <
> Sip-implementors <at> lists.cs.columbia.edu>
> Sent: Friday, July 13, 2012 11:31 AM
> Subject: RE: [Sip-implementors] Duplicate diversion headers in Invite
>

(Continue reading)

Saúl Ibarra Corretgé | 14 Jul 2012 12:14

Re: Duplicate diversion headers in Invite

Hi, 

On Jul 14, 2012, at 11:35 AM, Brez Borland wrote:

> Hi Vivek, inline
> 
> On Fri, Jul 13, 2012 at 7:52 PM, Vivek Singla <vivsingla <at> yahoo.com> wrote:
> 
>> Thanks Brett for the corrected number. So I was looking into this rfc, I
>> didn't see any error conditions mentioning a duplicate diversion header.
>> I am forgetting, but SIP has its own way of stopping the loops and looping
>> messages, isnt it?
>> I am trying to think of any header or a parameter which SIP client or
>> server look for in case of a loop.
>> I mean what if there are more than 2 duplicated entries in Diversion
>> headers.
>> 
> 
> Looking through the RFC5806 it doesn't mention that Diversion header can be
> used more than once neither. As I understand it implies redirection, and
> explicitly specifies the destination party (single/one), therefore
> duplication is not reasonable.
> 

Multiple Diversion headers are definitely allowed: http://tools.ietf.org/html/rfc5806#section-6.5

So, the fact they look the same doesn't imply that there is something wrong, IMHO.

Regards,

(Continue reading)

Vivek Singla | 13 Jul 2012 18:36

Picon

Re: Duplicate diversion headers in Invite

Thanks Brett, 
 
This RFC 5086 is 
Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation
            Service over Packet Switched Network (CESoPSN)

Is it the right one for Diversion?
 
Vivek. 

From: Brett Tate <brett <at> broadsoft.com>
To: Vivek Singla <vivsingla <at> yahoo.com>; "Sip-implementors <at> lists.cs.columbia.edu"
<Sip-implementors <at> lists.cs.columbia.edu> 
Sent: Friday, July 13, 2012 11:29 AM
Subject: RE: [Sip-implementors] Duplicate diversion headers in Invite

RFC 5086 is the historic RFC for diversion.  As far as I know, it does not forbid it.

The typical reason that you might see it involves looping.  A loop occurred and the device either handled
it differently or has not yet detected the loop (or reached Max-Forwards 0).

> -----Original Message-----
> From: sip-implementors-bounces <at> lists.cs.columbia.edu [mailto:sip-
> implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Vivek Singla
> Sent: Friday, July 13, 2012 11:58 AM
> To: Sip-implementors <at> lists.cs.columbia.edu
> Subject: [Sip-implementors] Duplicate diversion headers in Invite
> 
> 
> Hi,

(Continue reading)

Sharanabasavaraj Mathapati | 17 Jul 2012 14:53

Re: Mime parser for ISUP message in SIP body

Hi All,

Does any one know the MIME parser to parser ISUP message type in SIP
body?
Please suggest the open source if you know one.

Thanks,
Sharan

============================================================================================================================
Disclaimer:  This message and the information contained herein is proprietary and confidential and
subject to the
 Tech Mahindra policy statement, you may review the policy at <a
href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> 
externally and <a
href="http://tim.techmahindra.com/tim/disclaimer.html">http://tim.techmahindra.com/tim/disclaimer.html</a>
internally within Tech Mahindra.
============================================================================================================================

Srivastava, Gaurav | 19 Aug 2012 08:10

Re: Mime parser for ISUP message in SIP body

We would usually write our own specific parser for ISUP MIME.
The usual case would be that the C4 switch supports both SIP and SS7 messaging, in which case the SS7 message
parsing would already be implemented and would be used to parse SIP MIME as well.
Also, the parse logic would be very specific to how the given variant of ISUP ( ttc, itu , ansi) is implemented
on that platform, so I doubt you'd get a open source parser for this.

Gaurav.

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Sharanabasavaraj Mathapati
Sent: Tuesday, July 17, 2012 6:24 PM
To: sip-implementors <at> lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Mime parser for ISUP message in SIP body

Hi All,

Does any one know the MIME parser to parser ISUP message type in SIP
body?
Please suggest the open source if you know one.

Thanks,
Sharan

============================================================================================================================
Disclaimer:  This message and the information contained herein is proprietary and confidential and
subject to the
 Tech Mahindra policy statement, you may review the policy at <a
href="http://www.techmahindra.com/Disclaimer.html">http://www.techmahindra.com/Disclaimer.html</a> 
externally and <a

(Continue reading)

satish agrawal | 20 Aug 2012 16:57

Picon

Re: Mime parser for ISUP message in SIP body

Hi Sharan,

you should write your own MIME parser to parse ISUP message as per RFC 2045
in SIP message because it depends on
your implementation. I think no open source available.

Thanks,
Satish

On Tue, Jul 17, 2012 at 6:23 PM, Sharanabasavaraj Mathapati <
sharanb <at> techmahindra.com> wrote:

> Hi All,
>
> Does any one know the MIME parser to parser ISUP message type in SIP
> body?
> Please suggest the open source if you know one.
>
> Thanks,
> Sharan
>
>
> ============================================================================================================================
> Disclaimer:  This message and the information contained herein is
> proprietary and confidential and subject to the
>  Tech Mahindra policy statement, you may review the policy at <a href="
> http://www.techmahindra.com/Disclaimer.html">
> http://www.techmahindra.com/Disclaimer.html</a>
> externally and <a href="http://tim.techmahindra.com/tim/disclaimer.html">
> http://tim.techmahindra.com/tim/disclaimer.html</a> internally within

(Continue reading)

Return

Return to gmane.ietf.sip-implementors.

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane