11/26/2000: Thread: Sending Binary Data: 

In SIPForum, Naresh Kumar Agarwal asked that whether binary data can be sent in SIP.
- Jonathan suggested that SIP related questions be posted on the SIP mailing list NOT SIPForum and clarified that SIP can carry pure binary.
Resolved.

11/26/2000: Thread: Queries: 
In SIPForum, Naresh Kumar Agarwal asked following questions. 1. Is it possible  with in SIP framework for a redirect server to send back some data to the  client, which the client doesn't need to interpret but simply need to pass the  information along to a proxy server. 2. How to do challenge mechanism in SIP 3.  SIP supports PGP. How does the called party know the key.  - Jonathan again noted that SIP related questions be posted on the SIP mailing list. Anwering question 1: It is possible for redirect server to send some non-standard data through encapsulating in the header to client and client can send it to the proxy server. But proxy server and redirect server should have pre-arranged mechanism to understand the data. This is a dangerous thing to do. If you need something from SIP that is not already there, you should raise that issue instead of attempting non-standard extensions. 2. Although SIP provides digest authentication, which requires a shared secret between parties, it is better to use one of the already developed key exchange protocol. 3. See Ans 2. 

Resolved.

11/27/2000: Thread: SIP Security Abstract: 
Tom Tang initiated the discussion on security for SIP. He posted a small abstract on problem statement for security. There was no other follow-up discussion on this thread.

Not resolved. 

11/27/2000: Thread: Session Progress: 
Baniel Uri brought up an issue that in the bis 4.2.1, it is said that UAC should be ready receive the RTP data (according to SDP) as soon as it sends the invite request. But in 183 draft says, two way path needs to be established before UAC starts receiving data from UAS. Question: Why is the two way path need to be 
established for sending RTP information from UAS to UAC. - Henning replied that 183 draft is not valid anymore, it may be fold in to main spec. The question whether "Early media is undesirable and should be abolished" 
needs to be resolved in the IETF Meeting. - Jonathan seconded Henning that this issue needs to be discussed in IETF meeting.

Not resolved. To be discussed in the IETF meeting.

11/27/2000: Thread: 305 Reponse, What For? 

Emami-Nouri, Mohsen suggested that 305 response is not necessary and 301 & 302 can cover the 305 Response. 
- Billy Biggs responded that the wording implies that if you get a 305 you should send only that specific request through the proxy. Future requests within the call-leg should instead be directed at the old Contact address. He 
added that he thinks most implementers treat all 3xx responses almost identically.

Resolved.

11/27/2000: Thread: Many folks Draft Question: 

Ameet Kher requested a clarification on the latest many folks draft: For a UAS with no qos capability, should a comet be sent out by the UAS? - Bill Marshall responded that qos capable UAS responses are detailed in the 
section 4.2. If the UAS is not qos capable, it responds with no qos in the SDP. Call proceeds in best effort.

Resolved.

11/28/2000:Thread: Multiple SDP bodies in a SIP Message: 

Subhas Nayak asked whether it is possible to have multiple SDP messages in a SIP request ? 
- Jonathan replied that multiple SDP is not used in SIP. Only one SDP is allowed. He said he will make a note to add this point to the RFC.

Resolved. Note to be added in RFC.

11/28/2000:Thread: call-flow; each user has 2 UAs: 

Joshua Fox wanted to know what happens in a scenario when 2 UA s are in each endpoint dealing with two different media types communicating with one another. - Billy Biggs answered with an illustration that this type of scenarios can be  handled with 3pcc. Or with another app which monitors these two UA s.

Resolved.

11/28/2000: Thread: JAIN SIP Factory:

Chris Harris suggested that having all the create methods for all the messages  and headers in the JainSipFactory could be a problem and it can be too restrictive for an implementer. So it is better to define the create methods in 
the interfaces rather than JainSipFactory Class. Further he suggested that reflections and exceptions be used on the input parameters to the interfaces to differentiate between different implementations of JAIN SIP interfaces in an 
application. He noted that public review period for JAIN SIP spec closes today.- M.Ranganathan largely agreed with his proposal.

Resolved.

11/28/2000: Thread: Multiple Transaction Refer

Billy Biggs had the following proposal to solve failure of single transaction REFER. REFER looks the same, but it is responded with a 2xx if the far end accepts the REFER and intends to act upon it. A REFERDONE request which signals back that the spawned INVITE completed. Success or failure is indicated in some header (or in the body?). This request requires a header, Refer-CSeq or similar, to indicate which REFER transaction is being completed.
- Robert Sparks suggested that REFER (non-invite msg) does not have a timeout value defined by the protocol. (referring section 10.4.2., 10.4.1). Why can't we define a larger time-out value. - Billy Biggs replied that it is not good have transactions hanging for a long time. If half-a-minute is not enough, it is better to have multiple transaction.

Not resolved. No Conclusion.

11/28/2000: I-D ACTION:draft-hamer-sip-session-auth-00.txt submitted by Louis-
Nicolas Hamer

- Henry Sinnriech noted that (on page 9) 1. The service provider and access provider DO NOT NEED to be the same. 2. He also did not agree with the draft conclusion that it is not feasible to provision each network host with fixed routers and proxy servers. 3. He also did not agree to the draft proposal to extend RSVP, COPS/DIAMETER and SDP. 4. He also raised some concerns about the terminology like Bearer and Control. 
- Louis-Nicolas Hamer - 1.Agreed 2. In a wireless network, if the host is moving, it is not possible to have same fixed edge router. 3. He intends to extend RSVP, COPS and SDP to accommodate the ticket concept used in mobile network. 4. OK with some agreeable terminology.

Resolved/ Not Resolved. Both of them agreed to resolve their issues in the bar 
since there is not enough time address these issues in the meeting.

11/28/2000: JAIN SIP - Issues to be resolved
M.Rangathan: suggested that 1. whenever there is more than one header to be returned, it is better to return a vector than an array. 2. By letting receiver check for the validity of sent headers, we can cut down lots of setxxx API messages in the JAIN SIP Spec. 3. Parser should return portions of header which it cannot parser. This point will be moot if point 2 is accepted.

Not resolved. No further discussion.

11/29/2000: I-D ACTION:draft-ietf-sip-session-timer-04.txt was posted

11/29/2000: I-D ACTION:draft-ietf-sip-call-flows-02.txt was posted

11/29/2000: Threads: REFER for Remote Device Control:/ Music on Hold in ietf-
sip-service-examples-00

- Billy Biggs objected to the sip-peer-3pcc draft way of providing PHONECTL functionality using REFER. He said it is out side the scope of REFER and the meaning of the request is hidden in URI and it does not provide enough info to identify the call leg. He is planning to rewrite the PHONECTL draft by this week.

- Rohan Mahy asked Billy Biggs to show some example where the Request-URI, To, From, and Call-ID aren't sufficient to identify the call. Billy Biggs sited the Music on-Hold call flow scenarios from sip-service-examples draft and said the method=Bye in the REFER is insufficient to indicate the UA which call should be disconnected. 
- After numerous emails discussing this issue, Jonathan noted that SIP is a poor control protocol and should not be used as such. We should add text to REFER about the requirement and non-requirements of processing REFER at the endpoint.
- Rohan Mahy disagreed and said that REFER with some additional semantics is good enough for (Billy's requirement) the job. 
- Henry Sinnreich agreed with Rohan Mahy and observed that device control protocols like H.248 are poor engineering option. 

Not resolved.

11/29/2000: Thread: Processing BYE request at Proxy
Dongsung Kim had these following 2 queries: 1. If a proxy forks a INVITE downstream and the BYE response has lower Cseq than the INVITE request, what is should the proxy do ? 2. Is it possible for a proxy to generate a response to a BYE request under special cases ? 
- Jonathan replied as follows: 1. the proxy will proxy the BYE request as normal. The request is rejected by the UA. The response is forwarded by the proxy. 2. No. Proxies do not respond to requests. If a BYE is sent, it is 
forwarded. If there is a Route header, its used. If not, its forked. 

Resolved. 

11/29/2000 WG Last Call for draft-ietf-sip-guidelines-00.txt  

-- Dean Willis posted this. Jonathan corrected it is draft-ietf-sip-guidelines-01.txt and it will be treated as BCP.


11/29/200 WG Last Call on Caller Preferences posted by Dean Willis

11/30/2000 as if there wasn't enough traffic on this darn list...
Jonathan Rosenberg proposed that if we drop the SDP in ACK and SDP in PRACK, it will keep SIP simple and solve lots of confusion.Brett Tate noted that Broadsoft sends SDP in ACK for re-INVITE to avoid getting 
into SDP-Change-Loop discussed in "[SIP] 3PCC and the re-invite response".- Dave Oran noted that it is simple and better to let SDP in any leg of an INVITE transaction and just use most recent SDP sent or received. 
- Vladislav Zubarev noted that there are already applications implemented the SDP in ACK scheme: Ex: H.323-Sip Gateways. So he suggested that we continue to support this and recommend using reINVITE in future.
- Bryan Byerly noted that there are two commercial implementations of assured QoS using SDPs in PRACK. He suggested Jonathan's view is unwarranted restriction.
- Arjun Roychowdhury expressed concern that J's proposal will break H.323-SIP gateway although he has no objection to no SDP in PRACK proposal.
- Finally, Jonathan Rosenberg observed that the proposal is dead. Main reason being there are many commercial implementation of SDP in ACK available already.

Resolved.

11/30/2000: Thread: 3PCC and the re-invite response / Thread: Re: No SDP => take 
off hold?
- Gethin Liddell was concerned that according to 3PCC draft, it is possible for a USER to change its SDP in the re-INVITE response, which will cause inconsistency in the overall session set-up. 
- After numerous emails on this issue, Jonathan expressed this final following opinion: I think this thread, and several others, all relate to one central problem: we need a general way of describing SDP processing in UAs; how to determine what the "current" set of SDP is, and how one creates a response to an offered SDP. With a general algorithm in place for that, these problems would go away. I hope to cover some of these issues at the meeting.

Not resolved. Jonathan will raise the issue in the meeting.

11/30/2000: Thread: Single Line Extension work
Dean Willis brought up this issue to check whether this issue still open. 
- Brain Rosen notes that he was suppose to be working on this issue. Unless there is a draft, which explains the issue and a proposal to solve the problem, this issue is not a active WG item.

Resolved for now.

11/30/2000: Thread: Questions on draft-rosenberg-sip-app-components-00.txt

Alan Johnston asked following 3 questions on the draft: 1. On page 16, section 5.4, referring to Figure 3, should the SDP in re-INVITE look different? 2. In Figure 5, the IVR call flow shows RTP flow before 200 OK. In PSTN, any packets before call completion will be dropped. 3. In Figure 9, the Web Enabled Message Drops call flow, how the Web Caller's SIP URL is sent to the Controller, since the Controller initiates the INVITE (3). 
- Bert Culpepper replied , Answer for 1: I believe the authors leave it to the reader to decide how to build the SDP component to specify the desired media destinations. Using your example a complete media description will be as 
follows. 
m=audio 5004 RTP/AVP 0
m=audio 53000 RTP/AVP 96
c=IN IP4 200.201.202.203
a=rtpmap:96 telephone-event
The above indicates a different destination for the second media 
stream according to RFC 2327 (SDP).

Resolved - Q1 
Not resolved - Q2,Q3