headers
Wayne.Davies | 1 Dec 2004 03:58
Picon

Re: Connection Admission Control in SIP

Joanna,
        SIP preconditions if you have seen discussion about them on 
implementors or read the draft would seem the best fit here. Otherwise it 
may be possible to reduce the offered codec list based on some external 
logic (IPCIF, IP Calculated Impairment Factor | MOS etc). If the UA is 
offered only high bandwidth codecs, G.711, then you can use a 415 with 
Accept-Encoding offering a lower speed codec. When network congestion is 
determined to have passed the UA could go back to offering a full suite of 
codecs including G.711.

        QoS is a complex area - where using above measurement based CAC is 
limited in that you will selectively deny, or accept and a certain rate, a 
codec for a call. This determination is based on how the newtork is 
behaving now, or in the last 5min interval used for determination of a 
score. But network congestion is by nature dynamic and with nothing 
reserving the RTP flow on a hop-by-hop basis when signalling is complete 
may result in the call degrading or terminating after successful setup. 
But I digress you said lightweight and perhaps the first para is a start 
point.

Regards,

Wayne.

>Hi all,
>I'm developing a SIPServer and I would like to embed
>a light connection admission control (CAC) implementation.
>Does anyone have any idea of what could a SIPServer do
>in the means of CAC (for example, due to low bandwith, can 
>a SIPServer reject a call or interfere to the SDP body of an INVITE
(Continue reading)

Permalink | Reply | 0 comments |
headers
OmPrakashTripathi 70630 | 1 Dec 2004 05:16
Favicon

Re: [Sip] OPTIONS outside dialog

Hi,

   200 OK is the standard Response which one can expect or can send for any Out Of Dialog OPTIONS.
    In most of the cases devices cant understand the OPTIONS then its up to the Entity which sends the OPTIONS to
decide what to accept.

Om..

----- Original Message -----
From: Anil Bollineni <ABollineni <at> juniper.net>
Date: Wednesday, December 1, 2004 7:09 am
Subject: [Sip-implementors] [Sip] OPTIONS outside dialog

> Hi,
> 
>    Assume OPTIONS comes outside dialog, what are the possible 
> responsesthat are for OPTIONS, assume these are the same responses 
> for any
> request as defined in RFC 3261. Please clarify.
> 
> 
> 
> Thanks in advance,
> 
> Anil
> 
> 
> 
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
srivastava.vivek | 1 Dec 2004 05:11

RE: Purpose of the 182 Queued message.


182 response can be sent by the UAS to convey the status of call (if UAS
does not want to drop the call). UAC can play announcement "Please wait,
you are in Queue".

Vivek

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu] On Behalf Of Ramesh
Ramamurthy
Sent: Tuesday, November 30, 2004 10:11 PM
To: sip-implementors <at> cs.columbia.edu
Subject: [Sip-implementors] Purpose of the 182 Queued message.

Hi,
    What is the real use for the 182 message? I can't see anything
specific that Queued does that cannot be accomplished by the Ringing
message. I understand that Queued message is used to let the UAS know
that there are calls ahead of it. Does the UAS really care, all it needs

to do is wait. Can't we just use the Trying or the Ringing message for
this purpose. Is it used to play preconnect music or something like
that?

Thanks In advance

cheers
Ramesh
_______________________________________________
(Continue reading)

Permalink | Reply | 0 comments |
headers
prabhan | 1 Dec 2004 06:53
Picon

Sip clients using Radius server for backend authentication

Hello,
 Are there any Sip user agents which authenticate IP incoming calls ?

 Also would like to know if there are any Sip user agents which rely on
Radius server(back end authentication) to authenticate the incoming
calls ?

Thanks in advance,
 Prabha N
Permalink | Reply | 0 comments |
headers
mahesh akarapu | 1 Dec 2004 08:00

RE: 200 OK after recieving ACK

Hi,
I am attaching the ethereal captures, so as to be clear on the problem.
I am using the following network setup.

  HOST1---HOST2

HOST1(202.125.84.170) and HOST2(202.125.84.171) are windows-XP machines
with AOL instant messengers as the UAs. Now a sip call is initiated from
HOST1. I am attaching the ethereal capture on HOST2 where the problem
behaviour is seen.
Packets (1-11) in the capture show the case where the SIP call was
established and terminated normally. Packets (12-27) show the case where
i observed the problem behavior.
Please go through the capture and let me know your comments on this.

Regards
Mahesh

On Tue, 2004-11-30 at 20:49, Nataraju A B wrote:
> If you can send the message details it would be easy to find out the
> actual problem... 
> 
> Otherwise we could only find vague answer which may not be useful to
> your actual problem...
> 
> Best Regards,
> Nataraju A.B.
> 
> -----Original Message-----
> From: sip-implementors-bounces <at> cs.columbia.edu
(Continue reading)

Permalink | Reply | 5 comments |
headers
Chowdhury, Sayan (Sayan | 1 Dec 2004 09:04
Picon
Favicon

RE: Purpose of the 182 Queued message.

example of a real life service wherein 182 Queued can be used is a
Government Emergency Telecommunications Service(GETS) call type. This is a
regulatory requirement in many networks and provide specialized call
processing in the event of congestion and/or outages during an emergency,
crisis or war.On SS7 networks ,this kind of call identified through the
special access number and dialed PIN which the emergency personnel will
have.
A call is not failed but queued and prioritized till the circuits are seized
, in case of a SIP origination you may want to signal this back to the
originating UAC using a "182 Queued" message and the UAC can take neccessary
action as vivek says.. 
Cheers , 
Sayan

-----Original Message-----
From: sip-implementors-bounces <at> cs.columbia.edu
[mailto:sip-implementors-bounces <at> cs.columbia.edu]On Behalf Of
srivastava.vivek <at> wipro.com
Sent: Wednesday, December 01, 2004 9:41 AM
To: ramesh <at> peakss.com; sip-implementors <at> cs.columbia.edu
Subject: RE: [Sip-implementors] Purpose of the 182 Queued message.

182 response can be sent by the UAS to convey the status of call (if UAS
does not want to drop the call). UAC can play announcement "Please wait,
you are in Queue".

Vivek

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

Permalink | Reply | 0 comments |
headers
michael koehler | 1 Dec 2004 12:32

Re: 200 OK after recieving ACK

Seems that ACK is missing the userpart of the request line.

should be:

ACK sip:user <at> 202.125.84.170...

instead of

ACK sip:202.125.84.170...

my 5c

Michael

On Dec 1, 2004, at 8:00 AM, mahesh akarapu wrote:

> Hi,
> I am attaching the ethereal captures, so as to be clear on the problem.
> I am using the following network setup.
>
>   HOST1---HOST2
>
> HOST1(202.125.84.170) and HOST2(202.125.84.171) are windows-XP machines
> with AOL instant messengers as the UAs. Now a sip call is initiated 
> from
> HOST1. I am attaching the ethereal capture on HOST2 where the problem
> behaviour is seen.
> Packets (1-11) in the capture show the case where the SIP call was
> established and terminated normally. Packets (12-27) show the case 
> where
(Continue reading)

Permalink | Reply | 4 comments |
headers
mahesh akarapu | 1 Dec 2004 14:00

Re: 200 OK after recieving ACK

Hi Michael,

If you look at packets 1-11(this is the case where no 200 OK was sent
after ACK is recieved), there also the request line does not contain the
user part. I guess if it is because of the user part missing, then in
the first case also we should see 200 Ok after ACK. 

What are your comments on this.

regards
Mahesh 

On Wed, 2004-12-01 at 17:02, michael koehler wrote:
> Seems that ACK is missing the userpart of the request line.
> 
> should be:
> 
> ACK sip:user <at> 202.125.84.170...
> 
> instead of
> 
> ACK sip:202.125.84.170...
> 
> 
> my 5c
> 
> Michael
> 
> On Dec 1, 2004, at 8:00 AM, mahesh akarapu wrote:
>
(Continue reading)

Permalink | Reply | 3 comments |
headers
michael koehler | 1 Dec 2004 14:30

Re: 200 OK after recieving ACK

 From this point 1-11 looks fine, but 12-27 not and after several 
retransmissions the callee
hung up the call. Maybe someone more familar with the "RTC" stack drop 
a comment here.

 From my point of view even the first call could not work. Maybe have a
closer look at: rfc3261 / 17.1.1.3 Construction of the ACK Request.

Ok, rfc2543 does not point the use of request-uri values out like
rfc3261 does in this case, but even in rfc2543 i can only find examples 
like
these:

ACK sip:es <at> jove.cs.caltech.edu SIP/2.0
          Via: SIP/2.0/UDP north.east.isi.edu
          From: Mark Handley <sip:mjh <at> isi.edu>
          To: Eve Schooler <sip:schooler <at> caltech.edu> ;tag=9883472
          Call-ID: 2963313058 <at> north.east.isi.edu
          CSeq: 1 ACK

Regards,

Michael

On Dec 1, 2004, at 2:00 PM, mahesh akarapu wrote:

> Hi Michael,
>
> If you look at packets 1-11(this is the case where no 200 OK was sent
> after ACK is recieved), there also the request line does not contain
(Continue reading)

Permalink | Reply | 2 comments |
headers
ira kadin | 1 Dec 2004 14:27

RE: latest draf "ISUP/SIP mapping"

Hi All,

Is there any draft, specifying ISUP/SIP mapping, later than 3398 from December 2002 ?

Thanks in advance

Ira
Permalink | Reply | 0 comments |

Gmane