Sorry for posting again.
Is the RFC 4028 indicating that a proxy MUST increase Session-Expires
to be equal to Min-SE under the following conditions
1.if it is *not* so in the request received by it.
2. If it happens to be so while processing the request (as explained
in section 8.1, para 4)
or i
> I know people who attempt to cope with that by using the R-URI of the
> initial INVITE to attempt an in-dialog request if they haven't yet
> received a Contact. (Seems to be grasping at straws if you ask me, but I
> suppose its better than nothing.)
Contact was optional within rfc2543. Thus you
Iñaki Baz Castillo wrote:
> El Lunes 06 Abril 2009, Brett Tate escribió:
>> The following was one of the threads:
>> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020062
>> .html
>>
>> Read sections 12.1 and 12.1.1:
>>
>> "Within this specification, only 2xx and 101-199 res
El Lunes 06 Abril 2009, Brett Tate escribió:
> The following was one of the threads:
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2008-August/020062
>.html
>
> Read sections 12.1 and 12.1.1:
>
> "Within this specification, only 2xx and 101-199 responses with a To tag,
> where the requ
> > The following is a non service example.
> >
> > B2BUA aware of Session-Expires activated upon early dialog by UPDATE.
> > B2BUA does not receive refresh in time; it sends BYE towards called
> party
> > for 1 of multiple early dialogs for branch.
>
> Yes, in theory it can be implemented since i
Iñaki,
I don't think anyone is saying that you must implement your UAC to use
this capability. If your UAC has nothing where this is useful then it
need not bother.
But your UAS and Proxy should support it. And its not like its any huge
burden to do so. Others see value in this, and if they de
On Thu, 2009-04-02 at 16:12 +0530, ROHIT CHAUDHARY wrote:
> Wondering what should be the appropriate response to a SUBSCRIBE
> received with a recognized but unsupported Event. As far as I can see,
> the RFC talks of only responding with 489 to unrecognized events.
404 would also be reasonable --
On Fri, 2009-04-03 at 13:48 +0900, junpark wrote:
> Possible solutions that I have considered are as follows;
> 1. add P-Asserted-Identity or Remote-Party-ID header in 180 Ringing
> response.
> 2. add Reason header in 180 Ringing response.
>
> But I'm still not sure of anything.
> What is the bes
El Lunes 06 Abril 2009, Dale Worley escribió:
> On Sat, 2009-04-04 at 12:35 +0200, Iñaki Baz Castillo wrote:
> > AFAIK there is a case in which a dialog is not created: when the initial
> > SUBSCRIBE contains "Expires: 0".
>
> A SUBSCRIBE with "Expires: 0" will get a NOTIFY, so a dialog must be
> c
On Mon, 2009-04-06 at 08:22 +0200, Andreas Byström (Polystar T & M)
wrote:
> I have some problems matching an example of the P-Called-Party-Id
> header in rfc3455 with the ABNF for the same header (in the same spec)
>
> Section 5.1 in RFC3455 says the following:
> "5.2 P-Called-Party-ID header syn
El Lunes 06 Abril 2009, Brett Tate escribió:
> The following is a non service example.
>
> B2BUA aware of Session-Expires activated upon early dialog by UPDATE.
> B2BUA does not receive refresh in time; it sends BYE towards called party
> for 1 of multiple early dialogs for branch.
Yes, in theor
On Sat, 2009-04-04 at 12:35 +0200, Iñaki Baz Castillo wrote:
> AFAIK there is a case in which a dialog is not created: when the initial
> SUBSCRIBE contains "Expires: 0".
A SUBSCRIBE with "Expires: 0" will get a NOTIFY, so a dialog must be
created if one does not already exist.
Dale
_
> > > I prefer to just ask two simple questions:
> > >
> > > a) Is this feature implemented and used by some *real* SIP device?
> >
> > Yes.
>
> Any example?
The following is a non service example.
B2BUA aware of Session-Expires activated upon early dialog by UPDATE. B2BUA
does not receive ref
El Lunes 06 Abril 2009, Brett Tate escribió:
> > I prefer to just ask two simple questions:
> >
> > a) Is this feature implemented and used by some *real* SIP device?
>
> Yes.
Any example?
> > b) Is this feature useful?
>
> Concerning simultaneous ringing, it allows caller to release parties it
I have been trying to understand how the isup-oli parameter is being
implemented. From what I can tell it seems to be mainly implemented as
a SIP URI parameter and used in the From header. I have not seen it
used as a parameter to a tel URI, nor in headers other than "From:"
Also, in lieu of an RF
> I prefer to just ask two simple questions:
>
> a) Is this feature implemented and used by some *real* SIP device?
Yes.
> b) Is this feature useful?
Concerning simultaneous ringing, it allows caller to release parties it doesn't
want to answer.
It also allows UAC/B2BUA to release individual
Hi, RFC 3261 allows a UAC sending a BYE during early-dialog to
terminate just a branch (in case of forking). This is:
- Alice calls Bob through a Proxy.
- Proxy forks to Bob_1 and Bob_2.
- Bob_1 and Bob_2 reply a provisional response containing "Contact"
header and a copy of Record-Route (if prese
Thanks Guys for clearing this one!
On Sun, Apr 5, 2009 at 10:47 PM, Rockson Li (zhengyli)
wrote:
> Cool,
>
> The +sip.instance is actually defined in draft-ietf-sip-outbound based
> on RFC3840
>
> 9. Contact Header Field
>
> This specification extends the Contact header field. In particular,
>>Subscription for DTMF key presses ???
>>Definitively SIP world is getting crazy.
It's not that crazy - they are events after all. Regarding INFO, no "DTMF for
INFO" usage is RFC-approved. Also, INFO does not have any negotiation or
agreement mechanism for DTMF transport.
Unfortunately the
Please try OpenSIPS
BR,
Manoj
-Original Message-
From: sip-implementors-boun...@lists.cs.columbia.edu
[mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of
nadeige Da costa
Sent: Monday, April 06, 2009 11:58 AM
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-imple
No. The main problem appears to be someone's incorrect interpretation of how
to build a request-uri.
Concerning your NOTIFY, the request-uri should be the uri portion pulled from
the associated Contact, Record-Route, or Route entry.
See RFC 3261 concerning how to populate a request-uri. See
Laurent,
Thanks again. I can understand the reasons why it's important to use
a tel URI in the P-Asserted-Identity in the cases you identified,
versus an "email address style" SIP URI. Do you think that a
P-Asserted-Identity containing a SIP URI in the form of
sip:phone-num...@domain:user=phone
Hi,
Lets assume an INVITE request arrives at a proxy (which has the local
policy as Min-SE=90 and Session-Expires=1800) as follows
Session-Expires: 100
Min-SE: 150
I would consider the request as invalid and reject it with "400 Bad
Request" as Session-Expires MUST be >= Min-SE for any SIP reques
23 matches
Mail list logo
