As we know, when a new SUBSCRIBE occurs, it creates a dialog.
But what should one do when a BYE is received on a SUBSCRIBE dialog?
I don't think "405 Method Not Allowed" is right but maybe "481"?
I can't believe that BYE should clear the dialog because, IMO, BYE is
only
valid for INVITE-creat
Hi Iqnacio,
The port information in your SDP body tells about the port in which you will
receive the media,it does not give any information about the sending port.
So in the SDP body of your invite
You are saying that you will receive media on 10.168.123.12:57724.
Similarly in the 180 ringing
Hi Paul,
I agree that it isn't very clear; and I don't have strong opinion concerning
how to interpret the text. However the RFC3261 snippet appears to apply to
both Expires header and Contact parameter (at least associated with redirect
server interactions). RFC2543 allowed SIP-date (absolut
I thought the inquiry was wrt the Expires header, not the expires header
parameter. The text in 8.3 seems to be talking about what to do if the
value of the expires parameter is malformed. And that only applies to
use in Contact, and perhaps only for use by redirect servers.
So for instance I w
El Miércoles 15 Abril 2009, Ignacio Gonzalez Lopez escribió:
> * Which ports must comunicate with which ports?
> * 208.239.76.169:50106 > 10.168.123.12:50106 and
> 208.239.76.169:57724 > 10.168.123.12:57724 * or what?
MySP:
10.168.123.12:57724
Remote:
208.239.76.169:5
If I recall correctly, RFC 3263 does not indicate to iterate the NAPTR records
(beyond to find common transport type) and does not provide guidance concerning
"invalid" behavior associated with the NAPTR query results.
Thus my understanding is to act however you think best if NAPTR replacement
Dear all:
I'm new in SIP. I'm trying to develop a softphone. I'm testing my softphone
with sip.inphonex.com, when I make a call this is the resulting dialog:
MySP ---> Remote
INVITE sip:01152456...@sip.inphonex.com SIP/2.0
Call-ID: 4174e09979865945c6fc29f7b5dd4...@10.168.123.12
From: ;tag=123
RFC3261 section 8.3:
"The "expires" parameter of a Contact header field value indicates how long the
URI is valid. The value of the parameter is a number indicating seconds. If
this parameter is not provided, the value of the Expires header field
determines how long the URI is valid. Malform
Neel Balasubramanian wrote:
> [Neel]
> Malformed values typically be treated as 3600 and not as 0.
First, we generally don't specify what is done for invalid cases.
(If we did, in effect we would be extending the spec to that case and so
it would be valid.)
But IMO it makes sense in cases lik
See below.
Thanks,
Neel.
> -Original Message-
> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-
> implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
> Castillo
> Sent: Wednesday, April 15, 2009 9:08 AM
> Cc: sip-implementors@lists.cs.columbia.edu
> Subjec
2009/4/15 hanifa.mohammed :
> Hi all,
>
> 1. When expires header does not have any value, can it be treated as zero?
Not valid according to SIP BNF grammar.
> 2. Does any header or header paramter in SIP grammer accept a negative
> value?
I know no such headers, but any *custom* header could, o
(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
[mailto:sip-implementors-boun...@
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: sip-implementors@lists.cs.columbia.ed
Hi all,
1. When expires header does not have any value, can it be treated as zero?
2. Does any header or header paramter in SIP grammer accept a negative
value?
Pl clarify.
Thanks in adv,
Mohammed Hanifa
___
Sip-implementors mailing list
Sip-implem
Hi All,
Can any one quickly provide theclarification on the below query on DNS.
What should be the behaviour if resolving first NAPTR returns an Invalied
behaviour, can we go ahaead and perform the SRV query for the same or do we
need to go ahead in resolving with next NAPRT Record.
Thank
2009/4/15 Shanbhag, Somesh (NSN - IN/Bangalore) :
> 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.
Other devices use "line" parameter in Contact.
AFAIK, GRUU specification is the standard
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
[mailto:sip-implementors-boun...@lists.cs.columbia.edu]
2009/4/15 Sourav Dhar Chaudhuri :
> Hi.
> I want to know some details on rinstance parameter present in
> REGISTER request.
>
> This parameter is generating when I am registering using
> X-lite softphone.
rinstance is a propietary parameter (not defined in an RFC).
R
Hi.
I want to know some details on rinstance parameter present in
REGISTER request.
This parameter is generating when I am registering using X-lite
softphone.
Example of the REGISTER message generated by X-lite
REGISTER sip:180.144.203.102 SIP/2.0
Via: SIP/2.0/UD
19 matches
Mail list logo