<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://purl.org/rss/1.0/" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:syn="http://purl.org/rss/1.0/modules/syndication/" xmlns:admin="http://webns.net/mvcb/">
  <channel rdf:about="http://blog.gmane.org/gmane.ietf.sip-implementors">
    <title>gmane.ietf.sip-implementors</title>
    <link>http://blog.gmane.org/gmane.ietf.sip-implementors</link>
    <description/>
    <syn:updatePeriod>hourly</syn:updatePeriod>
    <syn:updateFrequency>1</syn:updateFrequency>
    <syn:updateBase>1901-01-01T00:00+00:00</syn:updateBase>
    <items>
      <rdf:Seq>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22308"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22307"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22306"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22305"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22304"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22303"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22302"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22301"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22300"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22299"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22298"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22297"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22296"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22295"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22294"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22293"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22292"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22291"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22290"/>
        <rdf:li rdf:resource="http://permalink.gmane.org/gmane.ietf.sip-implementors/22289"/>
      </rdf:Seq>
    </items>
    <image rdf:resource="http://gmane.org/img/gmane-25t.png"/>
    <textinput rdf:resource=""/>
  </channel>
  <image rdf:about="http://gmane.org/img/gmane-25t.png">
    <title>Gmane</title>
    <url>http://gmane.org/img/gmane-25t.png</url>
    <link>http://gmane.org</link>
  </image>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22308">
    <title>sip over TCP</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22308</link>
    <description>&lt;pre&gt;Hello, can someone please point me to the right direccion on finding some
infomarction/tutorial about SIP over TCP.

regards
Milton
&lt;/pre&gt;</description>
    <dc:creator>Milton Sanchez</dc:creator>
    <dc:date>2013-05-20T19:49:51</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22307">
    <title>Re: Query regarding session timer behaviour in SIP Stack</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22307</link>
    <description>&lt;pre&gt;
So this was a spontaneous re-INVITE, not motivated by session timer?
(It doesn't really matter, but it will help in understanding your case.)


Did this have an S-E in it? Did it have Supported:timer? Did it have a 
Min-S-E?

The RFC says:

    In a session refresh request sent within a dialog with an active
    session timer, the Session-Expires header field SHOULD be present.
    When present, it SHOULD be equal to the maximum of the Min-SE header
    field (recall that its default value when not present is 90 seconds)
    and the current session interval.  Inclusion of the Session-Expires
    header field with this value avoids certain denial-of-service
    attacks, as documented in Section 11.  As such, a UA should only
    ignore the SHOULD in unusual and singular cases where it is desirable
    to change the session interval mid-dialog.

But it doesn't say "MUST be present". So the UAS must be prepared for 
that case.


Note that the RFC talks about session refresh requests as if they were 
somehow distinguishable from INVITEs and UPDATEs used for other 
purposes. And the UAS behavior doesn't have different rules for the 
first request and subsequent ones. In reality there is no way to 
distinguish, so you really must assume that *every* INVITE and UPDATE 
will either serve as a refresh or else will cancel the timer.

So, if there was no S-E in the request, and there is none in the 
response, then it must cancel the timer. In this case the S-E in the 
response resets the timer to 19200 seconds. The UAC should realize that.


One question of course is why the BYE was sent.
I guess you are assuming it has something to do with a session timer 
expiring, but do you know that?


As I explained above, every reinvite and update resets (or cancels) the 
session timer.

The RFC doesn't come right out and say this, but it is implicit.


19200.


The draft says:

    Similarly, if the side not performing refreshes does not receive a
    session refresh request before the session expiration, it SHOULD send
    a BYE to terminate the session, slightly before the session
    expiration.  The minimum of 32 seconds and one third of the session
    interval is RECOMMENDED.

That would be after 568 seconds for an S-E of 600, and 19,168 seconds 
for S-E of 19,200. If the BYE was because of an assumed expiry of the 
session timer, then I don't know where the value came from.

Thanks,
Paul


&lt;/pre&gt;</description>
    <dc:creator>Paul Kyzivat</dc:creator>
    <dc:date>2013-05-20T19:03:40</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22306">
    <title>Query regarding session timer behaviour in SIPStack</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22306</link>
    <description>&lt;pre&gt;Hi All,

I have certain queries about the session timer behaviour in the SIP Stack.
The scenario is as follows :

         SIP Stack                                                                               N/w

At T0s
            INVITE  --------------------------------------------------------------------------------&amp;gt;
                                            (having SE=600 &amp;amp;Min-SE = 600 )

            100 Trying &amp;lt;---------------------------------------------------------------------------
            180 Ringing &amp;lt;-------------------------------------------------------------------------
            200 OK &amp;lt;-------------------------------------------------------------------------------
                                 (having Require:timer,SE=600,refresher=uas)
            ACK   ----------------------------------------------------------------------------------&amp;gt;

            &amp;lt;---------------------------------Call Connected ---------------------------------&amp;gt;

At this point the Call is connected and the session timer is started by SIP Stack when 200 OK from the Network is received by the SIP Stack.
After this, SIP Stack sends out a Re-INVITE with as the new offer(as the version number in the o-line is incremented here).

At T0+8s
             INVITE  ---------------------------------------------------------------------------&amp;gt;
               (Version number in o-line of Re-INVITE SDP is incremented by 1)

             200 OK &amp;lt;-------------------------------------------------------------------------------
                                          (having SE=19200,refresher=uas)

             ACK   ----------------------------------------------------------------------------------&amp;gt;

At T0 + 485s

             BYE   ----------------------------------------------------------------------------------&amp;gt;

The call is terminated with BYE by the SIP Stack after 485 seconds.

Here I have few doubts:

1) The refresher is network here in both the cases.
    The second 200 OK response is sent for the "Re-INVITE with new offer" containing the greater values of session timer than the first 200 OK.
    So, does the new value of Session-Expires=19200s in second 200Ok should be considered as session refresh request by the SIP Stack ?

2) Should the SIP Stack restart its session timer with the new value "19200" or if the SIP Stack should restart its timer with the old value "600" on receiving second 200 OK ?

3) Here, the call is terminated with BYE after 485 seconds by the SIP Stack.
    What should be the exact time to terminate the call considering the fact that SIP Stack is running the session timer with the values received in 200 OK responses?

Please share the references from the RFC to support the above queries.

Regards
Priya Arya




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
&lt;/pre&gt;</description>
    <dc:creator>Priya Arya</dc:creator>
    <dc:date>2013-05-20T18:12:49</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22305">
    <title>Re: Query for method name in Request URI</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22305</link>
    <description>&lt;pre&gt;
Yes, the implication is that the UAC should register.
Of course there are many issues with this.

You didn't say what sort of request you sent that got this response.
Hopefully it was a REGISTER request. In this case the old R-URI 
identified a registrar, and the contact in the 302 presumably identifies 
a different registrar you are requested to use. (This might arise as a 
result of load balancing.) In this case all is straightforward - the 
remainder of your REGISTER request remains the same, and the method 
parameter is really a no-op.

If you had sent some other message (e.g., an INVITE) and got this 
response, then the action is unclear. It might mean that you are 
forbidden to send requests without registering first. (That isn't 
something SIP expects, but some systems like IMS require this.) If so, 
then presumably it means to send a separate REGISTER (not derived from 
your INVITE), and then maybe you will be able to retry your INVITE using 
the same R-URI you had used before. But that is just speculation on my 
part. There is nothing in SIP that discusses such behavior.

Thanks,
Paul

&lt;/pre&gt;</description>
    <dc:creator>Paul Kyzivat</dc:creator>
    <dc:date>2013-05-20T13:52:39</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22304">
    <title>Re: FMT are mandatory in the MediaDescriptions("m=") line</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22304</link>
    <description>&lt;pre&gt;In General Proxies are not expected to look into the payload/SDP, they will relay it to the other party.
SBC's(B2B) need to look into the SDP and in this case it will send 400 as the SDP is malformed.

-----Original Message-----
From: Aman [mailto:amanpreeet.singh&amp;lt; at &amp;gt;gmail.com] 
Sent: Monday, May 20, 2013 3:38 AM
To: sip-implementors
Subject: [Sip-implementors] FMT are mandatory in the Media Descriptions ("m=") line

Hi All,

Looking for the views on, if the media format description &amp;lt;fmt&amp;gt; are mandatory to mention in the media descriptions (m=) line of SDPs.

RFC4566 section 8.2.3 says,

...

RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST use the payload type number as their "fmt" value.
...


how a state-full proxy/SBC should react, who is receiving the m= line having no fmt values like,

|v=0
|o=ABC-SIP 2000 1000 IN IP4 192.168.180.10 s=SIP Call c=IN IP4 
|192.168.180.10
|t=0 0
|m=audio 25218 RTP/AVP
|a=sendrecv
|a=rtpmap:0 PCMU/8000
|a=ptime:20


Cheers,
Aman
_______________________________________________
Sip-implementors mailing list
Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

&lt;/pre&gt;</description>
    <dc:creator>Kanumuri, Sreeram</dc:creator>
    <dc:date>2013-05-20T11:39:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22303">
    <title>Re: FMT are mandatory in the MediaDescriptions("m=") line</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22303</link>
    <description>&lt;pre&gt;
Yes; the ABNF indicates that it is mandatory.

  media-field = %x6d "=" media SP port ["/" integer]
                SP proto 1*(SP fmt) CRLF


The SDP is malformed; thus it can basically act how it wants.

In general, a proxy is not expected to act as protocol police or route based upon SDP.  Thus it would typically just relay the malformed SDP.

An SBC, may provide a media function and be a B2BUA.  Thus it may have a reason to decode/use the SDP.  The malformed SDP may cause it to a request or release the call.


&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-05-20T11:07:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22302">
    <title>Query for method name in Request URI</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22302</link>
    <description>&lt;pre&gt;

Hi,
I have a query for method available in Request URI.
According to rfc 3261 section 19.1.5
"If the URI contains a method parameter, its value MUST be used as the method of the request." 
Now suppose the UAC receives 302 Moved Temporary with Contact like 
sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com
Doest that mean the UAC need to send REGISTER request to sip:biloxi.com ?
If not then what is the meaning of this method name in the Request URI?

Thanks &amp;amp; Regards
Anand Kumar
&lt;/pre&gt;</description>
    <dc:creator>ANAND KUMAR</dc:creator>
    <dc:date>2013-05-20T10:53:36</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22301">
    <title>FMT are mandatory in the Media Descriptions("m=") line</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22301</link>
    <description>&lt;pre&gt;Hi All,

Looking for the views on, if the media format description &amp;lt;fmt&amp;gt; are
mandatory to mention in the media descriptions (m=) line of SDPs.

RFC4566 section 8.2.3 says,

...

RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST
use the payload type number as their "fmt" value.
...


how a state-full proxy/SBC should react, who is receiving the m= line
having no fmt values like,

|v=0
|o=ABC-SIP 2000 1000 IN IP4 192.168.180.10
|s=SIP Call
|c=IN IP4 192.168.180.10
|t=0 0
|m=audio 25218 RTP/AVP
|a=sendrecv
|a=rtpmap:0 PCMU/8000
|a=ptime:20


Cheers,
Aman
&lt;/pre&gt;</description>
    <dc:creator>Aman</dc:creator>
    <dc:date>2013-05-20T10:37:56</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22300">
    <title>Survey on SIP overload control algorithms</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22300</link>
    <description>&lt;pre&gt;Hello Folks.
 
SIP faces with overload issue recently due to its popularity.  Build-in overload mechanism cannot prevent overload effectively. Therefore, IETF SIP Overload Control (soc) Working Group works on IETF RFC "SIP Overload Control" currently.
http://tools.ietf.org/html/draft-ietf-soc-overload-control-12
 
A survey on SIP overload control algorithms (including IETF RFC "SIP Overload Control") can be downloaded from the following link free of charge.
Y. Hong, C. Huang, and J. Yan, “A Comparative Study of SIP Overload Control Algorithms,"Network and Traffic Engineering in Emerging Distributed Computing Applications, Edited by J. Abawajy, M. Pathan, M. Rahman, A.K. Pathan, and M.M. Deris, IGI Global, 2012, pp. 1-20.
http://www.researchgate.net/publication/231609451_A_Comparative_Study_of_SIP_Overload_Control_Algorithms
http://arxiv.org/abs/1210.1505
http://www.igi-global.com/chapter/comparative-study-sip-overload-control/67496
 
Control theorectic approaches have been applied to model the interactions between an overloaded SIP server and its upstream servers as a feedback control system in two different scenarios - redundant retransmission ratio control and round trip delay control (IEEE Globecom 2010 and ICC 2011).
 
"Mitigating SIP Overload Using a Control-Theoretic Approach" IEEE Globecom 2010
http://www.researchgate.net/publication/221284946_Mitigating_SIP_Overload_Using_a_Control-Theoretic_Approach
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&amp;amp;arnumber=5683124&amp;amp;url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5683124
 
Implementation of implicit SIP overload control in the real system
"An Efficient Earthquake Early Warning Message Delivery Algorithm Using an in Time Control-Theoretic Approach"
http://link.springer.com/chapter/10.1007%2F978-3-642-23641-9_15#
http://www.ipv6.org.tw/docu/elearning8_2011/1010004798p_3-7.pdf  
 
 "Design Of A PI Rate Controller for Mitigating SIP Overload" IEEE ICC 2011
http://www.researchgate.net/publication/224249824_Design_of_a_PI_Rate_Controller_for_Mitigating_SIP_Overload
Skype story published by Road Runner (TimeWarner Cable Inc.)
http://features.rr.com/article/01vBgtc8TR17z?q=Skype
http://ieeexplore.ieee.org/xpl/login.jsp?tp=&amp;amp;arnumber=5963029&amp;amp;url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5963029   
 
In addition, implicit SIP overload control solution using control theorectic approaches can be regarded as an engineering applications of control theory, as shown by the most popular answer to recent ResearchGate question "What are the new trends in control engineering?".
https://www.researchgate.net/post/What_are_the_new_trends_in_control_engineering
  
Best regards,
  
Winston Hong
Software Engineer
InBay Technologies Inc.
Ottawa, 
Canada K2K 1Y3
http://www.inbaytech.com/solutions.html 
       
&lt;/pre&gt;</description>
    <dc:creator>Yang Hong</dc:creator>
    <dc:date>2013-05-17T16:59:46</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22299">
    <title>Re: Clarification/recommendation needed on sip protocol</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22299</link>
    <description>&lt;pre&gt;
I'm not aware of an IETF proposed solution. 

However, you might be interested in 3GPP TS 24.341.


&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-05-16T11:10:10</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22298">
    <title>Clarification/recommendation needed on sipprotocol</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22298</link>
    <description>&lt;pre&gt;Hello to all.
I am working with jain sip based software and having the following issue:
while proxy sends sip MESSAGE request to UA transaction can be timed out
but message still delivered.
This may happen on any kind of channel due to network slow response,and on
tls/tcp channel due
to connection oriented nature of channel.
in case of tls/tcp message is stored in socket buffer and socket tries to
resend this packet.
When first time it tries to send the packet destination is not reachable
due to firewall/nat machine on the way to UA which removed the nat hole.
After some time UA will send either keepalive or some sip request and this
will cause nat hole to be reopened.
Since proxy socket received the data from UA it will resend all the data it
has for him in buffer and message will be delivered.
UA of course will send 200 OK for the message , but since transaction timed
out this response can not be send further.

Since B2BUA will try to send same sip message later on , UA will end up
with 2 or more duplicate messages received.
Similar situation may happen with any NON INVITE transaction.
Is there some rfc or some recommendation how this issue can be resolved?

Thanks and best regards
Yulian Oifa
Sipme LTD
israel
&lt;/pre&gt;</description>
    <dc:creator>Yulian Oifa</dc:creator>
    <dc:date>2013-05-15T20:04:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22297">
    <title>Re: Require header in ACK request</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22297</link>
    <description>&lt;pre&gt;Sumant,

If we have Require/Proxy-Require in Initial Invite, we can have the same (or) subset of tags in the ACK.
It will not server any purpose in sending new tags in Require/Proxy-Require in the ACK Request.
The Reason is ACK cannot be rejected. 

Its good not to add these headers in ACK as they serve no purpose.

This Text could have been worded better in 3261 : not to include these headers in ACK (as mentioned in Table2.)

-Sreeram.

-----Original Message-----
From: Sumant Gupta [mailto:sumantgupta&amp;lt; at &amp;gt;gmail.com] 
Sent: Tuesday, May 14, 2013 3:26 AM
To: sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
Subject: [Sip-implementors] Require header in ACK request

 Hi All,

As per 3261

"An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request".

 As per table 2 (rfc 3261) require header is not applicable in ACK request.

Does it serve any purpose if we send Require/Proxy-Require header in the ACK request?
Any reason why it is mentioned in RFC as older posts on this forum does not provide any concrete answer?

Regards
Sumant
_______________________________________________
Sip-implementors mailing list
Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

&lt;/pre&gt;</description>
    <dc:creator>Kanumuri, Sreeram</dc:creator>
    <dc:date>2013-05-14T13:20:16</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22296">
    <title>Re: Query related register</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22296</link>
    <description>&lt;pre&gt;
REGISTER is not a dialog forming request (although some say that it creates a "pseudo dialog").  The tag requirement was added to RFC 3261 for non dialog forming requests mostly because it was added for dialog forming requests; however some may find it beneficial when dealing with forking proxies.



If you look at section 10, you'll notice that only the Call-ID (not the tags) are associated with the binding.  Thus the Call-ID is the only "pseudo dialog" identifier.



I assume "login" means REGISTER.  If "logout" means sending REGISTER to remove the binding, there isn't much benefit to continue using the same Call-ID if the binding was removed.  However, these are the RFC 3261 recommendations.

Section 10.2 indicates:

"Call-ID: All registrations from a UAC SHOULD use the same Call-ID
    header field value for registrations sent to a particular
    registrar.

    If the same client were to use different Call-ID values, a
    registrar could not detect whether a delayed REGISTER request
    might have arrived out of order."

Section 10.2.4:

"A UA SHOULD use the same Call-ID for all registrations during a
 single boot cycle.  Registration refreshes SHOULD be sent to the same
 network address as the original registration, unless redirected."


&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-05-14T10:52:55</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22295">
    <title>Require header in ACK request</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22295</link>
    <description>&lt;pre&gt; Hi All,

As per 3261

"An ACK request for a 2xx response MUST contain only those Require and
Proxy-Require values that were present in the initial request".

 As per table 2 (rfc 3261) require header is not applicable in ACK request.

Does it serve any purpose if we send Require/Proxy-Require header in the
ACK request?
Any reason why it is mentioned in RFC as older posts on this forum does not
provide any concrete answer?

Regards
Sumant
&lt;/pre&gt;</description>
    <dc:creator>Sumant Gupta</dc:creator>
    <dc:date>2013-05-14T10:25:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22294">
    <title>Re: Query for Out of dialod Notify</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22294</link>
    <description>&lt;pre&gt;
RFC 6665 doesn't allow generating NOTIFY outside of a dialog; and it only continues to allow the implied REFER subscription for historical reasons.

However for interoperability or capacity reasons, some vendors allow (per configuration or negotiation) the ability to send NOTIFY without requiring the corresponding SUBSCRIBE.


&lt;/pre&gt;</description>
    <dc:creator>Brett Tate</dc:creator>
    <dc:date>2013-05-14T09:59:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22293">
    <title>Re: Query for Out of dialod Notify</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22293</link>
    <description>&lt;pre&gt;Hi,

I want to know that why these server send OOD notify. What is reason for the generation of OOD Notify.


Thanks
Gaurav Gupta

-----Original Message-----
From: Tarun2 Gupta
Sent: Tuesday, May 14, 2013 12:38 PM
To: Gaurav Gupta; sip-implementors
Subject: RE: Query for Out of dialod Notify

Hi Gaurav

Although the specifications do not support OOD NOTIFY, I have seen it being used for NAT keep alive, for getting some configuration data (via the XML body in NOTIFY).

Asterisk also supports handling OOD NOTIFY with "message-summary" event package.  This allows third party telephone switches and voicemail systems to set and clear MWI lamps to SIP phones configured on Asterisk.

Regards
Tarun Gupta
Aricent


-----Original Message-----
From: Gaurav Gupta
Sent: Tuesday, May 14, 2013 12:17 PM
To: Gaurav Gupta; sip-implementors
Subject: Re: [Sip-implementors] Query for Out of dialod Notify

Hi,

Rephrasing the question
Please let me know why server send out of dialog  notify? Please let me know the scenario in which out of dialog notify is useful.

Thanks
Gaurav Gupta


-----Original Message-----
From: Gaurav Gupta
Sent: Tuesday, May 14, 2013 11:56 AM
To: sip-implementors
Subject: [Sip-implementors] Query for Out of dialod Notify

Hi,

Subscribe creates a dialog in SIP, then why client can receive out of dialog notify


Thanks
Gaurav Gupta




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sip-implementors mailing list
Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

_______________________________________________
Sip-implementors mailing list
Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

&lt;/pre&gt;</description>
    <dc:creator>Gaurav Gupta</dc:creator>
    <dc:date>2013-05-14T08:44:38</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22292">
    <title>Re: Query for Out of dialod Notify</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22292</link>
    <description>&lt;pre&gt;Hi Gaurav

Although the specifications do not support OOD NOTIFY, I have seen it being used for NAT keep alive, for getting some configuration data (via the XML body in NOTIFY).

Asterisk also supports handling OOD NOTIFY with "message-summary" event package.  This allows third party telephone switches and voicemail systems to set and clear MWI lamps to SIP phones configured on Asterisk.

Regards
Tarun Gupta
Aricent


-----Original Message-----
From: Gaurav Gupta
Sent: Tuesday, May 14, 2013 12:17 PM
To: Gaurav Gupta; sip-implementors
Subject: Re: [Sip-implementors] Query for Out of dialod Notify

Hi,

Rephrasing the question
Please let me know why server send out of dialog  notify? Please let me know the scenario in which out of dialog notify is useful.

Thanks
Gaurav Gupta


-----Original Message-----
From: Gaurav Gupta
Sent: Tuesday, May 14, 2013 11:56 AM
To: sip-implementors
Subject: [Sip-implementors] Query for Out of dialod Notify

Hi,

Subscribe creates a dialog in SIP, then why client can receive out of dialog notify


Thanks
Gaurav Gupta




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sip-implementors mailing list
Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

_______________________________________________
Sip-implementors mailing list
Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

&lt;/pre&gt;</description>
    <dc:creator>Tarun2 Gupta</dc:creator>
    <dc:date>2013-05-14T07:07:41</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22291">
    <title>Re: Query for Out of dialod Notify</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22291</link>
    <description>&lt;pre&gt;Hi,

Rephrasing the question
Please let me know why server send out of dialog  notify? Please let me know the scenario in which out of dialog notify is useful.

Thanks
Gaurav Gupta


-----Original Message-----
From: Gaurav Gupta
Sent: Tuesday, May 14, 2013 11:56 AM
To: sip-implementors
Subject: [Sip-implementors] Query for Out of dialod Notify

Hi,

Subscribe creates a dialog in SIP, then why client can receive out of dialog notify


Thanks
Gaurav Gupta




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
_______________________________________________
Sip-implementors mailing list
Sip-implementors&amp;lt; at &amp;gt;lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================

&lt;/pre&gt;</description>
    <dc:creator>Gaurav Gupta</dc:creator>
    <dc:date>2013-05-14T06:47:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22290">
    <title>Query for Out of dialod Notify</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22290</link>
    <description>&lt;pre&gt;Hi,

Subscribe creates a dialog in SIP, then why client can receive out of dialog notify


Thanks
Gaurav Gupta




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
&lt;/pre&gt;</description>
    <dc:creator>Gaurav Gupta</dc:creator>
    <dc:date>2013-05-14T06:25:42</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22289">
    <title>Query related register</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22289</link>
    <description>&lt;pre&gt;Hi,
I have below two queries

1.     Totag, fromtag and call id are dialog identifier as per RFC3261, why we require all these three parameter? Why Only one parameter cannot act as dialog identifier?

2.     Is Call id a unique identifier for particular login. If we login after logout, how the call id will be changed.





===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
&lt;/pre&gt;</description>
    <dc:creator>Gaurav Gupta</dc:creator>
    <dc:date>2013-05-14T05:58:15</dc:date>
  </item>
  <item rdf:about="http://permalink.gmane.org/gmane.ietf.sip-implementors/22288">
    <title>What is the best SIP stack ?</title>
    <link>http://permalink.gmane.org/gmane.ietf.sip-implementors/22288</link>
    <description>&lt;pre&gt;I see there are 2 famous SIP stack: pjsip and doubango

What are the advantages of one over another ?

&lt;/pre&gt;</description>
    <dc:creator>Khoa Pham</dc:creator>
    <dc:date>2013-05-10T08:08:13</dc:date>
  </item>
  <textinput rdf:about="http://search.gmane.org/?group=$group=gmane.ietf.sip-implementors">
    <title>Search Engine</title>
    <description>Search the mailing list at Gmane</description>
    <name>query</name>
    <link>http://search.gmane.org/?group=$group=gmane.ietf.sip-implementors</link>
  </textinput>
</rdf:RDF>
