[Sip-implementors] Multiple non- 2xx responses

2006-01-13 Thread Andy Pandaram
Is it possible for a UAC to receive multiple non-2xx responses for an INVITE (because a call was forked and the forking proxy sent through both of them to a UAC)? What should be the UAC behavior in such a scenario? - Andy Send instant messages to your online friends

Re: [Sip-implementors] Multiple non- 2xx responses

2006-01-13 Thread Christer Holmberg \(JO/LMF\)
Hi, What you describe shouldn't happen, but if it happens I guess you could e.g. choose to simply ACK the responses... Regards, Christer -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andy Pandaram Sent: 13. tammikuuta 2006 10:21 To:

[Sip-implementors] capture device problem

2006-01-13 Thread neeraj kumar vishnoi
I am programming audio conference server and rtp mixer using jain sip api and jmf. In jmf programming my rtp transmitter is not getting any capture device. i have given audio format(audioFormat_LINEAR,8000,8). program is not getting any capture device corrosponding to this. if anyone have

Re: [Sip-implementors] Multiple non- 2xx responses

2006-01-13 Thread shivani . garg
Hi Andy, As per RFC 3261, Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response can be distinguished by the tag parameter in the To header field. Thus, each represents a distinct dialog, with a distinct dialog identifier. And the UAC

Re: [Sip-implementors] Multiple non- 2xx responses

2006-01-13 Thread Christer Holmberg \(JO/LMF\)
I thought the question was about non-2xx response... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 13. tammikuuta 2006 13:27 To: Andy Pandaram Cc: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu Subject: Re:

Re: [Sip-implementors] Multiple non- 2xx responses

2006-01-13 Thread Asheesh Joshi
I dont know if this case is possible. I think the stateful proxy will not forward all the non-2xx responses back to the originating UAC. You will only get one non-2xx response. Forking of INVITE at proxy will create new Transaction states which proxy should maintain and handle. Only when a final

Re: [Sip-implementors] G729a

2006-01-13 Thread Markolefas, Nikolaos
I would like to add my bit in the G729 conversation. The following line is syntactically incorrect. A proper sdp parser should return an error, and do not accept an SDP offer (or answer) including a=rtpmap:18 G729A/8000. Whenever not indicated, silence suppression (or voice activity detection)

Re: [Sip-implementors] Multiple non- 2xx responses

2006-01-13 Thread Nataraju A B
Comments inline... Thanks Regards, Nataraju A.B. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Asheesh Joshi Sent: Friday, January 13, 2006 5:54 PM To: Andy Pandaram Cc: [EMAIL PROTECTED]; sip-implementors@cs.columbia.edu; Christer Holmberg (JO/LMF)

Re: [Sip-implementors] Multiple non- 2xx responses

2006-01-13 Thread Anshuman Rawat
Here's the answer from Section 13.2.2.3 of 3261 - A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final

Re: [Sip-implementors] [Sip] Solutions to NAT: STUN

2006-01-13 Thread Álvaro Canivell García de Paredes
Hi there! 1-private addressport binding against public ip port My clients have private addresses, and the server, a public address. (besides, no dynamic IP) 2-keeping the binding alive by periodically. in case your NAT is symetrical and/or both clients are in same private domain you will

Re: [Sip-implementors] Multiple non- 2xx responses

2006-01-13 Thread Kasturi Narayanan
You said, Due malfunctioning by the proxy the UAC may receive the multiple non-2xx responses as part of the same call. If this new failure response received before the transaction was terminated then it can generate the same ACK which sent for the earlier failure response, but this response will

Re: [Sip-implementors] RFC4028 and 422 response to INVITE

2006-01-13 Thread Dale R. Worley
On Fri, 2006-01-13 at 12:15 +0200, [EMAIL PROTECTED] wrote: I was wondering why the new request should contain the same Call-ID, To and The session refresh request is an INVITE within an existing dialog, hence it needs to have the same identifiers as the dialog it is part of. From i.e. what

[Sip-implementors] Session Timers RFC 4028 typo?

2006-01-13 Thread Manpreet Singh
In Paragraph 9 for UAS Behavior there is a line stating: If the incoming request contains a Supported header field with a value 'timer' but does not contain a Session-Expires header, it means that the UAS is indicating support for timers but is not requesting one. The UAS may request

Re: [Sip-implementors] Is this a valid To header

2006-01-13 Thread Dale R. Worley
On Thu, 2006-01-12 at 16:25 -0500, Jerry Yin wrote: To: sip:[EMAIL PROTECTED] Can someone tell me if this is a valid to-header? It is definitely invalid, since {x-snom-ip} is not a hostname. You should yell at your service provider and make them change it. Dale

Re: [Sip-implementors] Distinguishing Initail Invite from ReInvit es.

2006-01-13 Thread Uttam Kumar Sarkar
Probably you must be storing the call-ids of all new calls. If the INVITE's call id matches your active call list then it's a re-INVITE. -Original Message- From: Ramesh [mailto:[EMAIL PROTECTED] Sent: Friday, January 13, 2006 10:56 AM To: sip-implementors@cs.columbia.edu Subject:

[Sip-implementors] silenceSupp atribute; Re: G729a

2006-01-13 Thread Albrecht . Schwarz
IMPORTANT: rfc3108 defines silenceSupp atribute, though rfc3108 refers to voice over ATM. Not many VoIP vendors support this... Please note the statement in RFC 3108 towards IP support as well: ... In keeping with this spirit, some of the attributes defined in this document can also be used in

Re: [Sip-implementors] Distinguishing Initail Invite fromReInvit es.

2006-01-13 Thread Jerry Yin
The way is to check the to-tag. If it is exist, it is a re-invite. Otherwise, it's the Invite. If the UA receives a invite with to-tag but there's no dialog, it should reject the request by a 481 Call Leg/Transaction Does Not Exist response. Jerry -Original Message- From: [EMAIL

Re: [Sip-implementors] Sip-implementors Digest, Vol 34, Issue 19

2006-01-13 Thread Manpreet Singh
As far as matching Re-invites, I would suggest don't just match the Call-ID but also match the tags to check for the messages within the same dialog. Also if the Request has a To Tag in it and its not an ACK, then one would know it is some sort of a mid dialog request and then further rules like

[Sip-implementors] RFC3265 SUBSCR/NOTIF methods

2006-01-13 Thread samy chbinou
Hi all, I have a doubt in using the SUBCRIBE method. Is it mandatory to use the REGISTER method prior the SUBSCRIBE or not? Cheers ___ Nouveau : téléphonez moins cher avec Yahoo!

[Sip-implementors] RFC3265 SpecificEventNotification

2006-01-13 Thread samy chbinou
Hi all, I have a doubt in using the SUBCRIBE method. Is it mandatory to use the REGISTER method prior the SUBSCRIBE or not? Cheers ___ Nouveau : téléphonez moins cher avec Yahoo!

Re: [Sip-implementors] [Sip-implementers] RFC4028 and 422 response to INVITE

2006-01-13 Thread Gupta, Ajay
The session refresh request would be a re-INVITE request or an UPDATE (and not the initial dialog establishing INVITE request) and within an existing dialog. So the refresh request should have the same Call-ID, To, From as in the previous request in order to qualify to be within the same dialog

Re: [Sip-implementors] RFC3265 SUBSCR/NOTIF methods

2006-01-13 Thread vimal srivastava
why? i could not locate anywhere in 3265 such requirement is mandated. cheers v. From: samy chbinou [EMAIL PROTECTED] To: sip-implementors@cs.columbia.edu Subject: [Sip-implementors] RFC3265 SUBSCR/NOTIF methods Date: Fri, 13 Jan 2006 20:56:41 +0100 (CET) Hi all, I have a doubt in using the