Hello Gaurav,
May be your sip client is learning the IP address (NAT) via some mechanism like
STUN etc. But I am not sure, why it only does for second REGISTER. May be its
designed that way that after learning, during re-REGISTRATIONs it will use the
learnt address.
One more interesting point
Hi Sumant,
According to RFC 3261, ABNF grammer, I guess we can accept the From: header.
scheme = ALPHA *( ALPHA / DIGIT / + / - / . )
From= ( From / f ) HCOLON from-spec
from-spec = ( name-addr / addr-spec )
*( SEMI from-param )
addr-spec =
Hi Deepak,
You may want to reject the second UPDATE with 491 Request Pending.
Thanks,
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext
deepak bansal
Sent: Wednesday, January 16, 2013
Hi Tarun,
According to the old saying Be liberal with receiving and strict while
delivering, B2BUA is doing best attempt to succeed the call.
Are you sure the BYE has come for intended Dialog? (Does the Call-Id,
From-Tag, To-Tag match?).
If BYE is catching 481, it means dialog matching rules
Hi Pranab,
8.1.1.6 Max-Forwards
The Max-Forwards header field serves to limit the number of hops a
request can transit on the way to its destination. It consists of an
integer that is decremented by one at each hop. If the Max-Forwards
value reaches 0 before the request reaches its
Hi Pranab,
(1) Re-INVITE from A to B: CSeq: 2 INVITE
(2) Re-INVITE from B to A: CSeq: 2 INVITE
(3) Call-ID shall remain same until BYE
Best Regards,
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
Hi Castillo,
(1) Yes, Definitely BYE has higher precedence and should be honored.
(2) 491 Request Pending should be sent.
(3) OPTIONS, it depends. UAS can reply with its capabilities right away.
Thanks,
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
Can you please send the offer SDP and answer SDP?
Thanks,
Somesh
-Original Message-
From: ext Aman Aggarwal [mailto:aman.aggar...@aricent.com]
Sent: Friday, October 14, 2011 11:47 AM
To: Shanbhag, Somesh (NSN - IN/Bangalore); sip-implementors
Subject: RE: [Sip-implementors] Dynamic
Yes, they can have the same. While parsing, a=rtpmap takes the highest
precedence.
We had encountered a similar situation in iterop where in we had to change the
code to take from the a=rtpmap as the precedence, rather than static payload
numbers.
But yes, if a=rtpmap for the corresponding
Typically the AOR will not be changed to the IP address. In Registrar,
typically the FQDN of the AOR will be retained. If Registrar is resolving the
FQDN in the AOR, then its wrong.
But from UAC pov, it should accept the call - again in principle with Be
strict while sending and be liberal
Hi Sunil,
Can you please brief about the actual scenario which you are facing?
It depends on invite transaction, non invite transaction and also the state of
the dialog you are in.
Thanks,
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
Hello,
(1) Yes, the Re-INVITE. Refer RFC 3261, RFC 3264 for more details.
(2) By using REFER method, Refer RFC 3515 for more details.
Regards,
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
Hi Abhishek,
Yes. Since the UPDATE is typically done to alter the SDP details in case of
early dialog, there might be a stateful-proxy (may be B2BUA) in between which
would want the SDP to be modified and sent forward.
So, its better to include the Route header in the UPDATE request if you
The UAS is not liking the SDP which the UAC has sent. Please send the SDP
which the UAC is sending.
Most probably, you will have one of the m= lines which it cannot understand.
Regards,
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
Please do attach the callflow with messages.
Thanks,
Somesh
-Original Message-
From: Verma, Salil (NSN - IN/Gurgaon)
Sent: Monday, July 04, 2011 12:47 PM
To: Shanbhag, Somesh (NSN - IN/Bangalore);
'sip-implementors@lists.cs.columbia.edu'
Subject: RE: [Sip-implementors] error 488
Hi
The traces indicate the cause value of 65 in Q.850 which states Bearer
capability not implemented.
This means UAS didn't like one of the fields in the following:
Access transport (9 bytes length)
Optional Parameter: 3 (Access transport)
In case of session-audit from SBC,
UAC Broadworks
INVITE ver=2
inactive
UAC-- Broadworks
INVITE ver=2
??
?? Should be a=inactive because UAC is already in hold. And also, earlier for
a=sendonly, UAC had got a=inactive.
-Somesh
-Original
Typically this is implementation dependent. As by the saying Be liberal in
receiving and strict in sending, we have to ignore the a= lines which are
extra and take only those lines which are specified in the codec list.
Typically the implementation will be such that you read the codec list and
When maddr (machine address) is with the request-URI, it has the highest
importance. The request shall be forwarded to the address received in maddr.
Best Regards,
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
I think B party must terminate with 400 Invalid Request and send BYE to the
existing dialog. It might be someone is snooping as well in the network.
-Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu]
Yes, that's possible. Only restriction is if the SDP is carried by reliable
1xx, you cannot change the SDP in 2xx.
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext SIP
Satan
Sent:
Yes, I would think if the call is going through different gateways before
reaching the callee. You are likely to get different types of announcements
being played.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
If a call goes through SBC, most SBC's (I have seen in AudioCodes SBC) will
have MEDIA_TIMEOUT mechansim, where it will detect the no media condition and
would teardown the calls on both sides.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
Goutam,
Normally the Step-II shall not happen. It could happen, if Bob's phone doesn't
want to have one way media or RTCP packets - in this case it can make the media
totally inactive.
May be to save some bandwidth :) but there will be SBC's midway of the call
which can detect the idle media
From: ext goutam kumar [mailto:gottybl...@gmail.com]
Sent: Wednesday, September 22, 2010 4:07 PM
To: Shanbhag, Somesh (NSN - IN/Bangalore)
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Call HOLD from both sides
Hi,
Yes, when Alice
I think its valid. But mostly you would end up getting the last negotiated SDP
from UAC.
Whats the specific use case?
Regards,
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Pete
-
From: ext Pete Kay [mailto:pete...@gmail.com]
Sent: Thursday, August 12, 2010 11:07 AM
To: Shanbhag, Somesh (NSN - IN/Bangalore)
Cc: Sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] SDP in re-invite
I am running a b2bua with freeswitch. It is fine until a Mitel UAS
starts
Yes! As Sunil pointed out, a=rtcp: port is used for specifying separately the
port for RTCP (generally used if rtcp_port != rtp_port+1) which is in accrdance
with RFC 3605.
a=inactive applies to the whole RTP stream.
Regards
Somesh
-Original Message-
From:
Actually in TU, if the dialog doesn't go into the establishment state, it can
go away after sometime.
This should trigger all the IST which it has created to go away as well. In
this case, the IST shall be in Proceeding state.
So, there has to be user defined establishment timer at TU level.
We
Typically the SUBSCRIBE shall catch 404 when the resource uri for which the
SUBSCRIBE request is meant for is not available or server couldn't find it.
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
I think most of the times it depends upon the implementation.
In one of the product which I had worked on, this was one of the configurable
options to be turned on if we have to detect some kind of rogue packets.
There will be different checks to be made to consider the packet as the rogue
and
I guess the RFC 3261 grammer shall not allow trailing semicolon with no header
parameters.
To= ( To / t ) HCOLON ( name-addr
/ addr-spec ) *( SEMI to-param )
to-param = tag-param / generic-param
tag-param = tag EQUAL token
generic-param = token [ EQUAL gen-value ]
In such cases 403 Forbidden shall have Retry-After header field giving the
number of seconds client has to wait before sending the next REGISTER request.
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
the media inactive.
Hope this helps,
Somesh
From: ext friend friend [mailto:sip_qu...@yahoo.co.in]
Sent: Monday, July 06, 2009 6:13 PM
To: sip-implementors@lists.cs.columbia.edu; shamik.s...@wipro.com; Shanbhag,
Somesh (NSN - IN/Bangalore)
Subject: RE: [Sip
Therefore, it is
RECOMMENDED that a UA only render the information in the Call-Info
header field if it can verify the authenticity of the element that
originated the header field and trusts that element. This need not
be the peer UA; a proxy can insert this header field into requests.
There is one more method we can use if we are not supporting session-timers. If
both UAC and UAS are terminating the media, it can check for the MEDIA_TIMEOUT
( Idle for some duration ) and taredown the call.
Somesh
-Original Message-
From:
I think if its RFC 3428, ist upto 1300 bytes, but depends on the MTU and other
parameters.
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext friend
friend
Sent: Thursday, June 04,
I am not sure of the question you are asking.
Looks like the capture has all the messages from UAS and there are no messages
from UAC.
BYE is being sent from UAC and 200 OK for BYE is received ( last message ).
If you are asking for the reason for BYE, it would be helpful if you can paste
the
My guess is that something it didn't like in SDP.
[offer]
v=0
o=- 3800 3800 IN IP4 10.99.1.1
s=-
c=IN IP4 10.99.1.1
t=0 0
m=audio 64580 RTP/AVP 18 8 0 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
[answer]
v=0
o=iS3000 1 1 IN IP4 10.99.11.1
s=-
If the REGISTER is coming without credentials and without Contact, basically
that means it's a Query.
So, I think we need to challenge it again because we cannot send the contacts
to a intruder.
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
friend friend [mailto:sip_qu...@yahoo.co.in]
Sent: Thursday, May 21, 2009 12:17 PM
To: sip fourm; Shanbhag, Somesh (NSN - IN/Bangalore)
Subject: RE: [Sip-implementors] REGISTER without Contact
In RFC 3665 :
Bob sends a register request to the Proxy Server containing no
Contact headers
Comments inline with [SSS]
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Vikas
Jayaprakash
Sent: Thursday, May 21, 2009 12:38 PM
To: friend friend
Cc: sip fourm
Subject: Re:
We can challenge the PRACK. But typically we would have had INVITE challenged
and verified the credentials and subsequent requests should carry the
credentials for getting processed.
The entity which has challenged INVITE can also challenge PRACK if the
credentials provided has expired ( I mean
Inline with [SSS]
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext
Krishna Rao Gurram
Sent: Friday, May 08, 2009 11:41 AM
To: sip-implementors@lists.cs.columbia.edu
Subject:
Thanks! Yeah I didn't see that. So, Accept and Accept-Encoding can have empty
value in deed!
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext Iñaki
Baz Castillo
Sent: Thursday, May
The basic thing is CALLEE has to take the subset of codecs offered by CALLER
and reply back.
But in your case, CALLEE is replying with different set of codecs (97 101) in
reply to CALLER codecs ( 102 0 8 106 )
IMHO, since the capabilities mis-match, immdiately end the call using BYE /
CANCEL
Peter Nijhuis
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
implementors-boun...@lists.cs.columbia.edu] On Behalf Of Shanbhag,
Somesh (NSN - IN/Bangalore)
Sent: maandag 27 april 2009 15:07
To: ext friend friend; sip fourm
Subject: Re: [Sip
And also as per RFC 2327, only v, o, s fields are mandatory in SDP
Somesh
friend friend wrote:
Hi,
Thanks for your response.
but RFC 2327 Grammar says like
media-field =m= media space port [/ integer]
space proto 1*(space fmt) CRLF
media =
At the very first, the transaction for 1st INVITE would have been created. And
when second INVITE comes, since the branch_id is different definitely it will
be a different transaction.
But it would eventually map to dialog created by first INVITE. But if the
SIPProxy supports spiral call
Yes, I think BYE is only for terminating the dialogs created by INVITE as per
RFC 3261.
Returning 481 Transaction doesn't exist is appropriate one
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On
I think its proprietory parameter. I also came across some one using ssig
parameter for contact and we had to maintain the contact intact along with it.
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
I think you need to go to next NAPTR record.
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of ext
kavitha menneni
Sent: Wednesday, April 15, 2009 6:52 PM
To:
(1) If Expires header doesn't have value, basically it violates ABNF of 3261
and it shuold be flagged as parser error
(2) Could be. But I don't think Expires is one of them
Somesh
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
53 matches
Mail list logo
