Je suis absent(e) du bureau jusqu'au 23/08/2010
Je suis absent jusqu'au 23 Aout. En cas d'urgence merci de contacter
Xavier Penellon (x.penel...@emessage.fr) (0139234889 ) qui vous orientera.
Remarque : ceci est une réponse automatique à votre message
"Sip-implementors Digest, Vol 88, Issue
Hi Uttam,
Thanks for your help.
Also, here i would like to pinpoint for payload 118(g.729 E) is that i
haven't seen any where which says we cannot have the 18 & 118 payload in one
SDP.
Apart from that yes i do agree with your statement for dynamic payload 120.
Please correct me if anything wron
what i feel that due to list of codecPACKET size is getting
increased hence it sending 488..
It should respond 488 because of packet size. If the SBC does not
support any codec from the offered list (18 0 8 35 36 2 38 39 40 41 42
43 44 45 46 47 4 80 3 56 118 101) then SBC can send 488.
I w
Dear All,
I am facing the issue with my SBC, where my source is sending me the
complete list of RTP payload and my SBC is returning back 488 Not Acceptable
here.
v=0
o=BroadWorks 148094714 1 IN IP4 209.58.101.249
s=-
c=IN IP4 195.189.150.38
t=0 0
m=audio 6300 RTP/AVP 18 0 8 35 36 2 38 39 40 41 42
Hi Uttam,
Here is my SBC, even is not forwarding the call to leg 2... Its first
sending the 100 Trying in the correspondence of Initial Invite and then
immediately sending 488 back to source UA.
UA INVITE--
SBC
UA <-100 TryingSBC
UA<--488 No
Hi Uttam,
Here is my SBC, even is not forwarding the call to leg 2... Its first
sending the 100 Trying in the correspondence of Initial Invite and then
immediately sending 488 back to source UA.
UA INVITE--SBC
UA <-100 TryingSBC
UA<--488 Not
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Nitin Kapoor
Sent: Friday, July 30, 2010 1:36 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] RTP payload list in OFFER
D
Additionally, RFC 5359 provides some example call flows for services such as
Call Forwarding.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Uttam Sarkar
> (usarkar)
> Sent: Friday, July 3
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
Vivek Singla
Sent: Friday, July 30, 2010 12:11 PM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Request URI, FROM ,TO heade
Hi,
In case of call forwarding, I have a question on Request URI and FROM and TO
headers.
When A calls B and B forwards the call to C.
The Invite from A has Request URI of B and FROM of A and TO of B.
Now when B forwards the call to C.
The Invite from B has the Request URI of C but it has the
On 07/30/2010 07:11 AM, marius zbihlei wrote:
> I have heard about CPEs/Sip stacks that don't work well with lr; param
> but instead require a lr=on; param explicitly set.
>
> Maybe this could also be the case(Of course this means that the system
> must still be 3261 compliant)
I tried that too,
Alex Balashov wrote:
> On 07/30/2010 04:59 AM, WORLEY, Dale R (Dale) wrote:
>
>
>> While 3261 systems should interoperate correctly with 2543 systems,
>> 2543 systems are considered obsolete these days.
>>
>
> I think the issue is that there is a proxy inserting an RR header with
> the 'lr
Hi Alex,
The proxy is not sip v1 compatible. Please go through "proxy behavior
while receiving request" section 16.4 in 3261.
It should check for its own entry in request uri.
Regards,
Sumit Jindal
On Fri, Jul 30, 2010 at 2:49 PM, Alex Balashov
wrote:
> On 07/30/2010 04:59 AM, WORLEY, Dale R (
On 07/30/2010 04:59 AM, WORLEY, Dale R (Dale) wrote:
> While 3261 systems should interoperate correctly with 2543 systems,
> 2543 systems are considered obsolete these days.
I think the issue is that there is a proxy inserting an RR header with
the 'lr' parameter in the middle of the flow. I'm
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Alex Balashov
[abalas...@evaristesys.com]
Actually, on review of one of the scenarios, it appears that I was
mistaken; the cookie is not in
From: Nitin Kapoor [nitinkapo...@gmail.com]
I just pinpoint the issue and noticed that we do not have the port in CONTACT
URI of 302.
Now when i checked the RFC, it never says that it is mandatory to have the port
in contact URI, but when i checked some
16 matches
Mail list logo
