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
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:
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
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
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:
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
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)
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)
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
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
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
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
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
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
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:
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
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
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
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!
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!
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
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
22 matches
Mail list logo