pranab sahoo | 2 Jun 10:20 2012
Picon

Need Help

Hi all,

          Its nice to have a platform for sip related discussion.

It's first time I am working in call forwarding.Really I have a doubt
in call forwarding and redirecting.

Suppose consider a scenario

     INVITE                   INVITE
    call id=1234            call id=?
    Max-forward=70       Max-forwrd=?
 A--------------------->B--------------------->C

so B going to forward the call to C.
so in this case

Will  B  behave like a proxy or user agent?
so call id will remain same for B------------->C or it will be different?
 and what about Max forward,if Max-forward=0 in A---->B,then call will
forward to C or not???
Ravi Kumar | 2 Jun 13:26 2012

Regarding RFC 5404

Hi All,

RFC 5404 section 
7.1.  Media Type Definition

int-delay:  

         int-delay = "int-delay:" source-delay *("," source-delay)

         source-delay = SSRC ":" delay-value

         SSRC = 1*8HEXDIG ; The 32-bit SSRC encoded in hex format

         delay-value = 1*5DIGIT ; The delay value in milliseconds

         Example: int-delay=ABCD1234:1000,4321DCB:640

         NOTE: No white space allowed in the parameter before the end of
         all the value pairs

7.2.  Mapping to SDP

   o  Any remaining parameters go in the SDP "a=fmtp" attribute by
      copying them directly from the media type parameter string as a
      semicolon-separated list of parameter=value pairs.

As per section int-delay parameter should be part of a=fmtp line and it
should have parameter as parameter=value pair.

But as per ABNF it should be int-delay:<value>
(Continue reading)

Paul Kyzivat | 2 Jun 16:05 2012
Picon

Re: Need Help

On 6/2/12 4:20 AM, pranab sahoo wrote:
> Hi all,
>
>            Its nice to have a platform for sip related discussion.
>
> It's first time I am working in call forwarding.Really I have a doubt
> in call forwarding and redirecting.
>
> Suppose consider a scenario
>
>       INVITE                   INVITE
>      call id=1234            call id=?
>      Max-forward=70       Max-forwrd=?
>   A--------------------->B--------------------->C
>
> so B going to forward the call to C.
> so in this case
>
> Will  B  behave like a proxy or user agent?
> so call id will remain same for B------------->C or it will be different?
>   and what about Max forward,if Max-forward=0 in A---->B,then call will
> forward to C or not???

Whether B acts as a proxy or a UA is up to it.
If it acts as a UA then we would call it a back to back UA (B2BUA).

If it acts as a proxy then 3261 is clear about how it should act.
It should forward the message on with the same callid and with the M-F 
value decremented to 69. If the incoming M-F value to B had been 0 then 
it must not forward.
(Continue reading)

Manoj Priyankara | 3 Jun 04:14 2012
Picon

CSeq in Registration process with 407

Good day Folks,

I have a doubt in the use of CSeq in the registration process that involve
407. Call flow is as follows

UAC
                                            UAS/Proxy
|-------F1 (REGISTER)------------------------------------------> |

|<-----F2 (407 With proxy-authenticate)---------------------  |

|-------F3 (REGISTER with proxy-autorization)-----------> |

|<-----F4 (200 OK)------------------------------------------------>|

Must the UAC use the same CSeq value throughout the complete registration
process? (That is both F1 and F3 have the same CSeq)

Or

Can the UAC increase the CSeq by one in F3 ?( That is, if CSeq of F1 is 1
and CSeq of F3 is 2)

Cheers!
Manoj
Brez Borland | 3 Jun 13:48 2012
Picon

Re: CSeq in Registration process with 407

Hi Manoj,

On Sun, Jun 3, 2012 at 3:14 AM, Manoj Priyankara <manoj0915 <at> gmail.com>wrote:

> Good day Folks,
>
> I have a doubt in the use of CSeq in the registration process that involve
> 407. Call flow is as follows
>
> UAC
>                                            UAS/Proxy
> |-------F1 (REGISTER)------------------------------------------> |
>
> |<-----F2 (407 With proxy-authenticate)---------------------  |
>
> |-------F3 (REGISTER with proxy-autorization)-----------> |
>
> |<-----F4 (200 OK)------------------------------------------------>|
>
> Must the UAC use the same CSeq value throughout the complete registration
> process? (That is both F1 and F3 have the same CSeq)
>
> Or
>
> Can the UAC increase the CSeq by one in F3 ?( That is, if CSeq of F1 is 1
> and CSeq of F3 is 2)
>

UAC MUST increase the CSeq number. For full answer to your question refer
to RFC3261, Section 8.1.3.5 Processing 4xx Responses, last paragraph on the
(Continue reading)

Tarun2 Gupta | 3 Jun 17:27 2012

Re: CSeq in Registration process with 407

Hi Manoj

The UAC must increase the CSeq value by 1 in the Register request with credentials.

Regards
Tarun Gupta
Aricent
________________________________________
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of Manoj Priyankara [manoj0915 <at> gmail.com]
Sent: Sunday, June 03, 2012 7:44 AM
To: Sip-implementors <at> lists.cs.columbia.edu
Subject: [Sip-implementors] CSeq in Registration process with 407

Good day Folks,

I have a doubt in the use of CSeq in the registration process that involve
407. Call flow is as follows

UAC
                                            UAS/Proxy
|-------F1 (REGISTER)------------------------------------------> |

|<-----F2 (407 With proxy-authenticate)---------------------  |

|-------F3 (REGISTER with proxy-autorization)-----------> |

|<-----F4 (200 OK)------------------------------------------------>|

Must the UAC use the same CSeq value throughout the complete registration
(Continue reading)

Paul Kyzivat | 3 Jun 19:01 2012
Picon

Re: CSeq in Registration process with 407

On 6/3/12 7:48 AM, Brez Borland wrote:
> Hi Manoj,
>
> On Sun, Jun 3, 2012 at 3:14 AM, Manoj Priyankara<manoj0915 <at> gmail.com>wrote:
>
>> Good day Folks,
>>
>> I have a doubt in the use of CSeq in the registration process that involve
>> 407. Call flow is as follows
>>
>> UAC
>>                                             UAS/Proxy
>> |-------F1 (REGISTER)------------------------------------------>  |
>>
>> |<-----F2 (407 With proxy-authenticate)---------------------  |
>>
>> |-------F3 (REGISTER with proxy-autorization)----------->  |
>>
>> |<-----F4 (200 OK)------------------------------------------------>|
>>
>> Must the UAC use the same CSeq value throughout the complete registration
>> process? (That is both F1 and F3 have the same CSeq)
>>
>> Or
>>
>> Can the UAC increase the CSeq by one in F3 ?( That is, if CSeq of F1 is 1
>> and CSeq of F3 is 2)
>>
>
>
(Continue reading)

Tarun2 Gupta | 4 Jun 09:06 2012

Same tags in To and From headers in 200 OK response

Hi All

Consider the following scenario:

UA 1                             B2BUA                         UA2
Invite (From tag F1)
--------------------------------->
                                    Invite (From tag F2)
                                    ---------------------------------->
                                    200 OK (From tag F2, To tag F2)
                                    <---------------------------------
200 OK (From tag F1,
              To tag F3)
<-------------------------------
ACK (From tag F1,
          To tag F3)
------------------------------->
                                    ACK (From tag F2,
                                                 To tag F2)
                                    ---------------------------------->

                        RTP
<------------------------------------------------------------------>

                                          BYE (From tag F2, To tag F2,
                                                To and From headers reversed)
                                    <----------------------------------
                                            481
                                    ---------------------------------->

(Continue reading)

Re: Same tags in To and From headers in 200 OKresponse

Hi Tarun,

According to the old saying "Be liberal with receiving and strict while
delivering", B2BUA is doing best attempt to succeed the call.

Are you sure the BYE has come for intended Dialog? (Does the Call-Id,
From-Tag, To-Tag match?).

If BYE is catching 481, it means dialog matching rules has one more
condition to check if From-Tag is not same as To-Tag which should have
been checked well before accepting the call. Since B2BUA has accepted
the call and now if its saying 481 for BYE, its problem with B2BUA :)

Okay, now if B2BUA has to reject the call well before, it can do so by
sending BYE towards UA2 (since UA2 has confirmed the dialogue) and 500
Internal Server Error towards UA1.

Thanks,
Somesh

-----Original Message-----
From: sip-implementors-bounces <at> lists.cs.columbia.edu
[mailto:sip-implementors-bounces <at> lists.cs.columbia.edu] On Behalf Of ext
Tarun2 Gupta
Sent: Monday, June 04, 2012 9:07 AM
To: sip-implementors <at> lists.cs.columbia.edu
Subject: [Sip-implementors] Same tags in To and From headers in 200
OKresponse

Hi All
(Continue reading)

Kevin P. Fleming | 4 Jun 13:21 2012

Re: CSeq in Registration process with 407

On 06/03/2012 12:01 PM, Paul Kyzivat wrote:
> OTOH, if you have no established registration state and so are doing an
> initial registration, you should be randomly be choosing a new Call-ID
> and CSeq. If*that*  request fails with a 407, IMO you have some options:
> - do just as above for a retry with registration state - same Call-ID
>     and incremented CSeq.
> - start over from scratch, with a new Call-ID and new CSeq, but with
>     Proxy-Authorize based on Proxy-Authenticate from the 407.

Interesting; as you say, REGISTER doesn't create a dialog, but I suspect 
that many UAs treat the state management similarly to a dialog (I know 
that Asterisk certainly does). Because of that, if the REGISTER retry 
doesn't use the same Call-ID, then it won't be accepted, because the 
nonce and other authorization related details are stored in that 
'dialog' structure, which won't be present when a new one is created for 
the new Call-ID.

> AFAIK these are equally acceptable.
>
> In this case, if you were to reuse the Call-ID but with a CSeq that is
> incremented by more than one, I would expect it to work. And even if you
> were to use a CSeq that was less it should probably work, because there
> should be nothing holding state with the prior value. But in these cases
> it can be argued that you aren't compliant.

I'm pretty sure that Asterisk will respond with an error if the retried 
request does not have a higher CSeq value than the original request, 
even for REGISTER and other non-dialog-forming requests. Essentially, 
the sequence of requests is treated as a 'dialog' during the 407/retry 
cycle. I don't remember this ever causing an interoperability problem.
(Continue reading)


Gmane