headers
Tang Xi | 1 Nov 2006 06:55
Picon

Query sending 200 for INVITE

Hi, I have a question for sending 200 for invite:

1>UAC sends an invite and precondition is set in the Require header, the SDP
in invite is like

m=audio 777 RTP/AVP 1 2 3
a=curr:qos local none
a=curr:qos remote none
a=des:qos ontional local sendrecv
a=des:qos optional remote sendrecv

2>UAS sends a 183 with SDP like this

m=audio 888 RTP/AVP 1 2 3
a=curr:qos local none
a=curr:qos remote none
a=des:qos optianal local sendrecv
a=des:qos optianal remote sendrecv
a=conf:qos remote sendrecv

3>UAC sends prack back and UAS sends 200 for Prack, both of them don't
contain SDP.

After the above steps completed, UAS shall wait for the UAC to send request
(maybe UPDATE)  with SDP, indicating that "Reservation Conf". My question is
how long shall UAS wait? Is there any timer to prevent UAS from waiting
forever?

Thanks in advance
Tang Xi
(Continue reading)

Permalink | Reply | 1 comment |
headers
sumitv@aftek.com | 1 Nov 2006 08:28
Favicon

Allow header field

Rfc 3261 section 20.5 says :-

"All methods, including ACK and CANCEL, understood by the UA MUST be
included in the list of methods in the Allow header field, when present."

My question whether REGISTER Method is to be added in Allow header field 
or not?
Because REGISTER is also one of the sip methods.

Since REGISTER is one of the necessary operations we don't add it?

Thanking you,

Waiting for your reply,
---Sumit
Permalink | Reply | 2 comments |
headers
Gaurav Kheterpal | 1 Nov 2006 08:00

Re: No charge indication in 183 session progress

It appears that you want to decide whether to charge/ not charge early media
- a ring back tone or announcement selectively whatever may be the case so
you are looking for a mapping between ACM & 183.

You may refer to RFC 3204 and use the SIP INFO method to insert ISUP
messages during a call to send out the charging information. Also refer to
Section 3.3 & 5.4 in RFC 3372 for details on how this can be achieved using
SIP-T.

I am not sure you can map any of the backward indicator/ charge indicator to
a 183 message directly; at least there is no mention of the same in RFC
3960.

I hope this helps.

Regards,
Gaurav

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Ganesh
Pitchiah S
Sent: Thursday, October 19, 2006 2:02 AM
To: Sip-implementors <at> cs.columbia.edu
Subject: [Sip-implementors] No charge indication in 183 session progress

Hi All,

I am facing a situation here some calls should not be charged. This will
be indicated in ISUP ACM message I need to convert this to 183 Session
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gaurav Kheterpal | 1 Nov 2006 08:19

Re: Allow header field

A closer look at RFC 3261 will explain that the methods listed in Allow
header are to be invoked from within a dialog:

Sec 13.2.1 -> An Allow header field (Section 20.5) SHOULD be present in the
INVITE.
   It indicates what methods can be invoked within a dialog, on the UA
   sending the INVITE, for the duration of the dialog.  For example, a
   UA capable of receiving INFO requests within a dialog [34] SHOULD
   include an Allow header field listing the INFO method.

Section 13.2.2.1 ->  Header fields present in a provisional
   response are applicable as long as the dialog is in the early state
   (for example, an Allow header field in a provisional response
   contains the methods that can be used in the dialog while this is in
   the early state).

Section 10.2 -> A REGISTER request does not establish a dialog.

And the assumption that ' Since REGISTER is one of the necessary operations'
is completely absurd. Section 10.2.1 indicates that a "A SIP UA can choose
to register...". This notion is especially true for B2BUAs and peer to peer
calling. A UA may or may not choose to register.

I hope this helps.

Regards,
Gaurav

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Divya Sachdeva | 1 Nov 2006 08:31
Picon

Register Request

I hve a question regarding REGISTER request
Can one UA register to the same registrar with two names in order to
redirect different users to different ports? For example register as userA
for port 5060 and as userY for port 5051? In that case should both
registrations have the same call-id?

Thanks and Regards
Divya
Permalink | Reply | 8 comments |
headers
Balaji.Murlitharan | 1 Nov 2006 09:07
Favicon

Re: Register Request


Communication powers the world. 
Aricent powers communications.

FLEXTRONICS SOFTWARE SYSTEMS IS NOW ARICENT.

"Divya Sachdeva" <divyasachdeva2005 <at> gmail.com> 
Sent by: sip-implementors-bounces <at> cs.columbia.edu
11/01/2006 01:01 PM

To
sip-implementors <at> cs.columbia.edu
cc

Subject
[Sip-implementors] Register Request

I hve a question regarding REGISTER request Can one UA register to the 
same registrar with two names in order to
redirect different users to different ports?

[Balaji Says]
Yes... U can do it with a single register request. Check the CONTACT 
header in the Register request. You can place the different name in that.
[Balaji End]

For example register as userA for port 5060 and as userY for port 5051? In 
that case should both registrations have the same call-id?

[Balaji Says]
(Continue reading)

Permalink | Reply | 5 comments |
headers
jafer sharif mohammed | 1 Nov 2006 09:16
Picon

REDIRECT SERVER

Hi,
     I have one question. As we are aware that REGISTRAR SERVER, REDIRECT
SERVER AND PROXY SERVER can be single logical entity. Assuming that user is
registered and binds its address, and sends a request, if this request is
received by proxy, so here my question is under what cirumstances REDIRECT
SERVER is contacted, and if above three servers are different entities, then
for every request generated REDIRECT SERVER is contacted, usually PROXY
SERVER consult the location database and route the request, so please
clarify.

 Regards.
  Jafer.
Permalink | Reply | 1 comment |
headers
Balaji.Murlitharan | 1 Nov 2006 10:15
Favicon

Re: REDIRECT SERVER


Communication powers the world. 
Aricent powers communications.

FLEXTRONICS SOFTWARE SYSTEMS IS NOW ARICENT.

Hi Jafer,

Main purpose of the Redirect server is giving the contact details of the 
UA which is not available in the same domain. The redirect server have the 
information of the all domain details,. See the following scenarios,

a) Say If  an  UA  "  X <at> first.com "   wants to communicate to   UA " 
Y <at> first.com " then the proxy for the first.com contacts the Location 
service (It will updated by the REGISTRAR) to get the details of the 
Y <at> first.com

b) But If an  UA  " X <at> first.com  " wants to communicate to  UA  " 
Z <at> second.com " then the proxy for the first.com contacts the Redirect 
server to get the details of the "  Z <at> second.com. "

Hope this helps .......

Thanks
Balaji Murlitharan.C

"jafer sharif mohammed" <siprnd <at> gmail.com> 
Sent by: sip-implementors-bounces <at> cs.columbia.edu
11/01/2006 01:46 PM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Divya Sachdeva | 1 Nov 2006 10:28
Picon

Re: Register Request

Thanks But i am little confused as from RFC 3261 Section 10 page 58
it says

Call-ID: All registrations from a UAC SHOULD use the same Call-ID

header field value for registrations sent to a particular

registrar.

If the same client were to use different Call-ID values, a

registrar could not detect whether a delayed REGISTER request
might have arrived out of order.

which means for

 registering userA for port 5060 and userY for port 5051 in different
REGISTER request In
that case both registrations will have the same call-id

On 11/1/06, Balaji.Murlitharan <at> aricent.com <Balaji.Murlitharan <at> aricent.com>
wrote:
>
>
>
>
>  *"Divya Sachdeva" <divyasachdeva2005 <at> gmail.com>*
> Sent by: sip-implementors-bounces <at> cs.columbia.edu
>
> 11/01/2006 01:01 PM
(Continue reading)

Permalink | Reply | 4 comments |
headers
Vivek Gupta | 2 Nov 2006 01:26

Re: Register Request

In this scenario, both userA and userY are altogether different 
identities (AOR) of the UA. Both points to indiviual entries in the 
location service and hence should have different call-ID values. As per 
RFC3261, you have to retain the call-id value for a particular identity.

Divya Sachdeva wrote:
> Thanks But i am little confused as from RFC 3261 Section 10 page 58
> it says
>
> Call-ID: All registrations from a UAC SHOULD use the same Call-ID
>
> header field value for registrations sent to a particular
>
> registrar.
>
> If the same client were to use different Call-ID values, a
>
> registrar could not detect whether a delayed REGISTER request
> might have arrived out of order.
>
> which means for
>
>  registering userA for port 5060 and userY for port 5051 in different
> REGISTER request In
> that case both registrations will have the same call-id
>
>
>
>
> On 11/1/06, Balaji.Murlitharan <at> aricent.com <Balaji.Murlitharan <at> aricent.com>
(Continue reading)

Permalink | Reply | 2 comments |

Gmane