headers
Song, Youngsun | 1 Jun 2006 01:55
Favicon

Re: Proxy Timer C processing - how does it help?

Sachin,

YoungSun 

> -----Original Message-----
> From: sip-implementors-bounces <at> cs.columbia.edu 
> [mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Sachin
> Sent: Thursday, May 04, 2006 5:58 AM
> To: sip-implementors <at> cs.columbia.edu
> Subject: [Sip-implementors] Proxy Timer C processing - how 
> does it help?
> 
> Hello,
> 
> According to RFC if Timer C fires at proxy, it should 
> generate CANCEL (provided 1xx was received). Now if the 
> CANCEL gets 200 OK but the original INVITE does not receive 
> any final response, what should the proxy do? Won't the 
> INVITE client transaction continue to hang forever? Won't 
> this beat the purpose of Timer C, which is there...
> 
> "In order to handle the case where an INVITE request *never* 
> generates a final response,..."
> 
> 
>          INV              INV
> UAC ------------> P1 --------------> UAS
>          100              100
>     <------------    <--------------
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Song, Youngsun | 1 Jun 2006 01:56
Favicon

Recall: Proxy Timer C processing - how does it help?

Song, Youngsun would like to recall the message, "[Sip-implementors] Proxy Timer C processing - how does
it help?".
Permalink | Reply | 0 comments |
headers
Song, Youngsun | 1 Jun 2006 02:11
Favicon

Re: Proxy Timer C processing - how does it help?

Sachin,

(sorry for the previous response sent by a mistake.)

Per the following text in Section 9.1, the INVITE client transaction
should be terminated after 64*T1 seconds after sending the CANCEL. I
think the proxy would send a 408 to the UAC in this case although I
couldn't find any specific reference to this.

"Note that both the transaction corresponding to the original request
and the CANCEL transaction will complete
independently. However, a UAC canceling a request cannot rely on
receiving a 487 (Request Terminated)
response for the original request, as an RFC 2543-compliant UAS will not
generate such a response.
If there is no final response for the original request in 64*T1 seconds
(T1 is defined in Section 17.1.1), the
client SHOULD then consider the original transaction cancelled and
SHOULD destroy the client transaction
handling the original request."

YoungSun

> -----Original Message-----
> From: sip-implementors-bounces <at> cs.columbia.edu 
> [mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Sachin
> Sent: Thursday, May 04, 2006 5:58 AM
> To: sip-implementors <at> cs.columbia.edu
> Subject: [Sip-implementors] Proxy Timer C processing - how 
> does it help?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Szabo, Barna | 1 Jun 2006 08:22
Picon

user agent header

Hi,
sending a User_agent header like this:
User-Agent: peerthings release P2P.Rel1.2.015.DELTA -> atw117m0

the Jain-Sip stack throws exception. Can anyone tell me what is wrong in
it?

thanks

Barna Szabo
Permalink | Reply | 13 comments |
headers
Marco Ambu | 1 Jun 2006 08:59
Picon

Re: user agent header

Szabo, Barna ha scritto:
> Hi,
> sending a User_agent header like this:
> User-Agent: peerthings release P2P.Rel1.2.015.DELTA -> atw117m0
>
> the Jain-Sip stack throws exception. Can anyone tell me what is wrong in
> it?
>
> thanks
>
> Barna Szabo
[RFC 3261 - pages 221, 231] ==> Wrong header syntax because
1) character '>' is not allowed in token
2) User-Agent Header field = "User-Agent:" server-val *(LWS server-val)
3) server-val = token [/token] / comment
comments are inside '()'

Marco Ambu
Abbeynet S.p.A. (www.abbeynet.it)
Permalink | Reply | 12 comments |
headers
Dmitry Goldberg | 1 Jun 2006 09:12
Favicon

Re: user agent header

 User-Agent header allows only tokens (and comments in parentheses). The
symbol ">" is not a token, so it is not allowed within this header.

Regards,

 
Dmitry

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Szabo,
Barna
Sent: Thursday, June 01, 2006 09:23
To: sip-implementors <at> cs.columbia.edu
Subject: [Sip-implementors] user agent header

Hi,
sending a User_agent header like this:
User-Agent: peerthings release P2P.Rel1.2.015.DELTA -> atw117m0

the Jain-Sip stack throws exception. Can anyone tell me what is wrong in
it?

thanks

Barna Szabo

_______________________________________________
Sip-implementors mailing list
Sip-implementors <at> cs.columbia.edu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sarju Garg | 1 Jun 2006 14:36
Favicon

Re: user agent header

Hi all,

I have a query. I wish to implement voice mail service using SIP. I am aware 
of CC-Diversion parameter but it is not still part of standard SIP. Is there 
any message/parameter to implement this service.

Thanks in advance

Regards
Sarju

----- Original Message ----- 
From: "Marco Ambu" <marco.ambu <at> abbeynet.it>
To: "SIP-implementors mailing list" <sip-implementors <at> cs.columbia.edu>
Sent: Thursday, June 01, 2006 12:29 PM
Subject: Re: [Sip-implementors] user agent header

> Szabo, Barna ha scritto:
>> Hi,
>> sending a User_agent header like this:
>> User-Agent: peerthings release P2P.Rel1.2.015.DELTA -> atw117m0
>>
>> the Jain-Sip stack throws exception. Can anyone tell me what is wrong in
>> it?
>>
>> thanks
>>
>> Barna Szabo
> [RFC 3261 - pages 221, 231] ==> Wrong header syntax because
> 1) character '>' is not allowed in token
(Continue reading)

Permalink | Reply | 11 comments |
headers
hema ramesh | 1 Jun 2006 12:49

BYE message

Hi.

Is there a possibility for a caller to receive a BYE from the callee 
before the session is established?
In such cases, what is the response expected from the caller?

--

-- 
Regards,
Hema Ramesh.
Permalink | Reply | 5 comments |
headers
Frank Shearar | 1 Jun 2006 15:19
Favicon

Re: BYE message

"hema ramesh" <rhema <at> techmahindra.com> asks:

> Is there a possibility for a caller to receive a BYE from the callee
> before the session is established?
> In such cases, what is the response expected from the caller?

Let's say A calls B, sending an INVITE. B accepts the call, sending a 200
OK. It's conceivable that B might immediately terminate the call, sending a
BYE. Network problems might cause that BYE to arrive at A before the 200 OK.
(I guess this could only happen in using UDP.) At that point (presuming
there've been no dialog-establishing provisional responses), A will have no
choice but to reject the BYE with a 481 (as per RFC 3261 section 15.1.2),
because it has not yet established a dialog.

Then the 200 OK arrives, and that establishes a dialog, as far as A's
concerned. However, B thinks the session's terminated. I'm not sure what
happens then (except for A getting annoyed and hanging up).

frank
Permalink | Reply | 4 comments |
headers
Gadigeppa Malagund | 1 Jun 2006 15:35
Picon

Re: BYE message

Here Callee should not send BYE untill it recieves ACK for 200.
So no question of BYE reaching caller before 200.

Regards,
Gadi

On 6/1/06, Frank Shearar <frank.shearar <at> angband.za.org> wrote:
>
> "hema ramesh" <rhema <at> techmahindra.com> asks:
>
> > Is there a possibility for a caller to receive a BYE from the callee
> > before the session is established?
> > In such cases, what is the response expected from the caller?
>
> Let's say A calls B, sending an INVITE. B accepts the call, sending a 200
> OK. It's conceivable that B might immediately terminate the call, sending
> a
> BYE. Network problems might cause that BYE to arrive at A before the 200
> OK.
> (I guess this could only happen in using UDP.) At that point (presuming
> there've been no dialog-establishing provisional responses), A will have
> no
> choice but to reject the BYE with a 481 (as per RFC 3261 section 15.1.2),
> because it has not yet established a dialog.
>
> Then the 200 OK arrives, and that establishes a dialog, as far as A's
> concerned. However, B thinks the session's terminated. I'm not sure what
> happens then (except for A getting annoyed and hanging up).
>
> frank
(Continue reading)

Permalink | Reply | 2 comments |

Gmane