1 Sipping session November 6th ******* New Speaker: Welcome to the sipping session. We have some problems with the projection. We can get going in the mean time. First of all we -- note you all have the welcome envelope. There is a problem. We will be changing the laptops. I think it is the laptop, actually. First of all we need a note taker. We need a volunteer note taker. Okay. Spencer will be taking notes. We need a back up note taker, another please. Okay. Make sure that wireless is not in-- if someone can actually transcribe from Java room. Okay. No volunteers. If Java is in the Java room and sees question, you have a supplementary web page. There you have -- you can go to the working group last call progress. What is next so that you can actually go there see who is reusing the documents and see what is upcoming. We have requests last meeting to put this online. So this is what we did. If you find different information, we can improve it. We are updating that web page monthly, so it should be up to date. We have been requesting charter updates. Amazingly enough, they never get to the official page. This is a merging of the last charter update, and it never makes it there actually. We decided to add it to the working group. Have a look at them and see if you have comments or 2 anything like that. The spread sheets-- they already had the working group items. So you can actually check them. You can download the slides and look at the charter request if you have any questions actually. I think this -- we can see conference packets that was actually waiting for a long time and now it is there. We have actually 3 documents, and the- there was like a last- minute change that RFC had requested. It should be out there in a matter of days. We had the-- most of them were moved to sip, and they will go along with the consent framer. We will coordinate all these efforts. We will resolve the last recently. We need--we have actually requested the publication of this recently and the v 6 transition graph. Recently we have completed the transition group last call. You can see it has already been the attribute -- dial up usage. Dial-up usage there will be a draft coming up shortly and we will be able to ship it out. We see any comments so people actually can have a last look at it and we will be requesting the publication 2 or 3 weeks. Consent as I said we are coordinating the last call resip. Some tellicating reviews we are discussing the last issues for the servers and hopefully right after the isg. On ending addition configuration framework, it seems that 3 some discussions are starting in the mailing list. Be active there, discuss the open issues. Basically, some people are saying we will have to consider the complexity we are having there. Please meet with the people that are interested in that. It has been important for 5 years, exactly. New Speaker: The individual- the contents for config has been kind of going along for a while, at what point do you have a sense of when it will be ready to go and take those on? New Speaker: I would like to get an agreement. And the last idea we have organized a meeting with some people that they were interested in the config framework. We will be doing that again. And we will find out the progress of this work. Okay. So this is what I mentioned before. We had a bunch of working group items and they were moved to sip and the publication was requested there. And this has to do with the sip change process, so it has to go from sip not from sipping. New Speaker: If you are going to comment on these, make sure it all goes to the sip list, even if you want to send it to the sipping list as well New Speaker: We just put this here if they wondered where these documents have gone. 4 New Speaker: They are going to be changing- New Speaker: They have disappeared. If you were wondering what has happened with these, it is fairly easy to follow. New Speaker: We posted this to the list when this happened. New Speaker: Probably, you didn't have time to check the new charter proposal. These are the new 5 working group items, so they are in the new charting group proposal. And when they are approved, they will become the new working group items. Okay. Agenda for today- any comments? This is the agenda for Tuesday. We can discuss the agenda on Tuesday. As you can see, actually, it was on Wednesday. We got only one hour for the second session, so we don't have as much time as we usually do. We couldn't fit all the agenda requests that you see. A lot we have rejected them. We got like a couple of slides from the authors from a couple of drafts to present the status. We would like to comment on some discussions that were going on in the mailing list regarding the effectiveness regarding the rate that we are producing documents in sipping. The same discussions that are going up again. Do we need editors and reviewers? I don't see any problem with reviewers. The success rate we get is excellent. 5 New Speaker: We have had complete reviews for 13 documents and we had a good success rate. New Speaker: It is excellent New Speaker: Many thanks. New Speaker: At this point I don't think we are lacking cycles. We can not revise documents timely. In the future is to basically appoint editors for working group items. We appoint one person with cycles to work on the documents. So if this happens in the future, be aware that otherwise -- having said that we have the text messages for ipv 6. We have actually an open issue as to whether use square brackets for addresses. And basically Robert was given important feed back from the sipping on what to do and finally the recommendation is to follow the robustness principal. The addition will be out there very shortly. And then we got the management draft little field. Basically defines the management request for management sessions. The reason the author believes that it is difficult to reach firewalls for management, and they are using subscribe notify mechanism. Do the authors want to talk one minute about that? New Speaker: All right. This is an update for session policy grafts. This is sip working group item right now. The draft has been under review by a number of 6 reviewers and had a lot of feed back. I would like to thank the reviewers for providing the feed back. I think that was great. And there are changes and modifications that were made to the graft. I actually don't want to go through all the details, but in general we have added some behavior for some things that were missing. And lots of things that were clarified and things that were edited, things like that. There is one issue that came up and that was essentially the question the proxy should be able to correlate with the invite that user is sending out. The proxy would know the user agent has contacted a policy server. If the proxy doesn't know that the user agent has done anything with those -- if they did it before. The proxy knows the user agent has contacted the policy server but doesn't say whether they were applied or not. We have couple of options: There should be no correlation at all. Another option would be to-- the user should connect to the policy server and then if the policy server and the proxy-- if they want to--could make this information available to the proxy and the proxy could check if the user agent and that would not require any changes to policy framework. Or that's another alternative that should be proposed that the token to the invite and sends it out to the proxy and the proxy would know that 7 the user agent has contacted the policy server. One way to do that is to provide the user agent to the policy server and then the proxy could go to policy server. Are there any opinions on that? If there are no strong feelings, I propose we go with 0 one. New Speaker: I have one concern, what stops it from -- New Speaker: It is a hint that it went to policy server but doesn't say anything about description. The assertion would be too strong. It doesn't say anything about the session description. New Speaker: Do we have a clear requirement to make sure it is not lying? New Speaker: The idea what you can do right now is the user agent goes to the policy server and fetches the policy that it could apply to the session this is something the proxy would need to figure out. New Speaker: When a proxy gets this, what is it supposed to do with it? I think that has an affect on the server? New Speaker: I don't think there is a strong requirement for doing that. I think for the proxy-- but there is no strong requirement -- it doesn't provide. New Speaker: You don't obey the session problem. It will reduce the session regardless of whether you include it or not. If you can lie about it-- 8 New Speaker: Exactly. New Speaker: I think for simplicity I would like no correlation. If I provide the caller idea, if there are any, if I provide it the policy server as well. It would be easier to not have the correlation at all. New Speaker: If you lied about the -- it would not provide New Speaker: I understood. Actually, policy enforcement is outside the scope of this document. The correlation wouldn't be used to say -- he has applied the proper policies. The user agent has seen the policy and is doing everything he can to apply with that. I would say that having a way to correlate just to see that the user has seen the policy and is doing what he can to meet them New Speaker: Could you identify yourselves at the mic? New Speaker: It wasn't about the policy server being contacted. It was in terms of routing if the media is supposed to go through some relay. It needed to make the same decision when it issues the secondary invite. The token needed to come from the policy server. You know that ua came from policy server. So you know that ua came from there. New Speaker: So I was going to ask whether there was discovery aspects to the server. If the reinvite goes 9 to different proxy? If there is state involved? You would have to find the policy server that was contacted. You would have to find the right one. That would be similar to the one like the dreaded media authorization token. To include the address information. And then in that model, one wouldn't work. You would need a token. New Speaker: The address of the policy server in there. New Speaker: With the media authorization is opaque. What I would suggest an id address plus a token so you could allow for data so you could find the right server. Policy server url New Speaker: I'm lost. I thought -- if you are complying the policy it will send it back to policy New Speaker: It could do whatever it wants to do to enforce the policies, if the proxy doesn't want to do policy enforcement. The proxy makes sure the user agent knows the address of the policy server but it doesn't make sure it uses the -- New Speaker: If it is applying what the policy has- New Speaker: There is no correlation. New Speaker: I think I understand the case for routing- have your invite go to the same proxy that you used. New Speaker: We got some people that say they need a correlation and a few people who said that it is not needed. If there is a problem, we go with the token and 10 move on. New Speaker: The even-- the proxy can not do enforcement anyhow. If it was -- there was not enough information. The signaling was correct. It doesn't solve the whole problem. Does anyone oppose to add the token thing? New Speaker: The only issue that we had- New Speaker: You can go to spreadsheets and see when it is scheduled. New Speaker: One thing- I was noticing that the policy fields you are using- something to protect them. Would you do it as the proxy inserts it? New Speaker: I think that was suggested by someone. I don't know. New Speaker: We can take that discussion for the list as soon as he produces the request for the identifier. New Speaker: This is the changes for policy and the feed back that I got from reviewers, a couple of changes. (Feedback from sound system) New Speaker: One issue that we have for the event package. This is the event that the user agent uses to subscribe to specific policies. Actually, this is the -- here in the back. This is hello. Clip it on your shirt. That microphone -- it is okay in the back. New Speaker: One 2, 3. New Speaker: This is the event package that user agent 11 uses to subscribe to policy server, and which information should a user agent subscribes to policy server. It should- we want to avoid any negotiation where it says there is not enough information -- a proposal would be a user agent controls all fields. We need to define basic set of elements. I will talk about -- the idea is essentially, the user agent populates all the fields. It has data for such a document. This was the only open issue for this daft, and I think this is-- New Speaker: Regarding the open issue is good, we don't want this mechanism to become too complex. We should go with a simple solution. New Speaker: Right now we have it targeted for January. New Speaker: It is not on. New Speaker: Okay. I was saying we have targeted in January at the same time as the document in sip. This is one of documents that we are working on- last call New Speaker: So this is the last policy the user agent profile data set for media policy. Again, there has been a number of changes and clarifications for reviewer feed back. On the last meeting, we wanted to send user information to the policy server. I have extended the format, so now it is possible to encode and send it to the policy server. There is an issue that I still need to do the definition needs to be moved. There's a 12 dependency issue here because both other policy drafts and this other policy depends on this. New Speaker: This is a reason to advance this configuration. New Speaker: These are the elements that added. That can be used to describe the session. Essentially there is an element for a request uri -- call id -- contact -- info-- max bandwidth -- and stream -- containing -- media type -- codec -- local uri -- remote uri. And I mean the idea would be that user agent fills in the elements it can fill in for this format to describe a session. Are there any comments? This is an example, the idea is that in the beginning there is a context session that essentially contains the contact and the information that contains the request uri there is a state element that has media type and the coding with the local uri and that is basically the description of the session. New Speaker: This change is good because we before -- this makes for shorter session policy documents New Speaker: This is a change to what is currently sessions that would describe all the codings and all the media types and independent of a stream and now we are encoding and saying this a media screen and there is the coding, and I think it is more compact version. 13 Okay. The second issue is regarding the policy elements that are returned to policy server and it should be really basic and should only have necessary elements. And one is ipinip intermediary. New Speaker: We have been working on requirements and things like that and I don't think anybody would use this. People wanted to do this kind of thing, and we have a set of elements, and they do useful stuff and not more so- I don't see any problem with that. New Speaker: Independent of the session, these elements would add the maximum user-- New Speaker: A long the lines, I don't see that there is anyway lines of implementation and get that to work. There is not enough specification. New Speaker: This is the minimum amount that user agent can count on. New Speaker: That would be a minimum band that user agent -- New Speaker: You may -- there was comment on the configured intermediary that you send a policy that has session with ip addresses and you get back in the policies and one comment that was actually to the policy framework whether the user agent in parallel or whether the user agent needs to contact the user server sequentially. It goes into policy server first and it 14 has the outside and goes to the next and so this element requires essentially that user agent sequentially contacts policy servers. However, this element was finally used in all the examples for session specific policies. And it seems to be important. I suggest we keep this. It may not be a problem. One or 2-- New Speaker: We need to do it because of that. In the current draft, I didn't see any motivation for doing that. New Speaker: All right. So this is essentially the -- we need to finish the format and definition needs to be -- New Speaker: Next one up is Jonathan -- overload requirement. New Speaker: All right. Before we get started as advertisement. Rye group there will be tutorial on ice after lunchtime in one of the rooms. I think I advertised. Let me know that you are coming -- we will talk about overload requirements. There are not a lot of changes in this. The actual requirements in the document. They are completely unchanged. I believe they are stable. New Speaker: It is ballroom A during the lunch break 11:30 to 1:00 -- tutorial on ice, send me a e-mail and let me know you want to come. Come after me later if 15 you need to know how. I had the simulation model what is the purpose. A request the last 2 meetings Allison in particular and others from the tsv who are interested and have studied congestion control they need something they can throw into ns and plug in there congestion control. It was partly addressed to that community to give them something to play with. Also, as the solution work gets going, provide a vehicle for analyzing how those do. And if they are competing proposals. We could use this model or more likely to tune whatever algorithm. Just as general technique to understand the simulation model. 3 parts to simulation model -- network model -- large number of user agents small number of edge proxies that they talk to smaller number of -- go between home proxies and make that change. Very basic model here. Having this hierarchy here helps you simulate how the algorithm works. We are dealing with large numbers of clients and relative of clusters and similar sizes of clusters so it is a good tool for simulating all the effects. This an a proxy model. -- messages come in to a queue -- mostly for figuring out whether it is emergency call or response and reject it right away without doing full processing. Determine whether it was 911 call or whatever it goes into appropriate queue. And then again it is modeled as a 16 service consuming a certain number of cycles and which would vary whether it was request or response invite or noninvite and then send it off. New Speaker: I am not comfortable with this model, how does it relate to general concepts that you describe? New Speaker: I made it as minimal as it had to be -- overload. Three part step to simulate to allow priority calls to go through or immediately reject response. It consumes cycles to reject responses and provide upstream feedback that you are overloading. New Speaker: My discomfort is that -- 4 different proxies at this point. I see different -- different separation of what goes -- all of the proxies I see have some sort of separation of the stuff that they do at beginning and what they do later, what goes in what bucket seems to vary pretty widely New Speaker: It is a simulation tool. It evaluates and demonstrates the problem in a simple environment -- you would just tune the parameter. This classification whether it is request response or emergency call and rejection of request in case of overload. Any other questions or comments? So there is also user agent model that I didn't have a picture for -- generating transactions some are invite some are noninvite. There is not much more to it than 17 that. So the next steps here- there has been a discussion on the list. Simulation and kind of analytic background -- seems like a good subject for a professor, if you want to comment on it. I need to poke for tsdwg input and get feedback on that. Other than that, it is done. We are well into solution. New Speaker: I have been doing this in Columbia. New Speaker: And you are the masters student. New Speaker: Traffic between home proxies. And what is the purpose of this? New Speaker: I agreed to do that New Speaker: One quick comment. There is work going on in the malas graph on performance evaluation. Somebody should see that we are talking about the same things. New Speaker: The malice draft is- and sip I didn't see direct relationship New Speaker: They are not related at all. New Speaker: Thank you for the model. We have got a -- looking at it this is purely editorial. At the end where there is a list of parameters, some of them are in -- Could you add another column it would be easier to read? New Speaker: That is good feedback. New Speaker: It is scheduled to happen in March for this document. We have so many working group last calls. We 18 don't want to over do it. New Speaker: This is the overload-control graft. The stages of this draft. Essentially we have combined the 2 overload into this graft, and the goal of this draft is essentially to explore the design space and see what we can do, and provide an initial proposal. There was a debate of this scope of overload control. It is used when a sip server does not have the resources to process all incoming sip messages. It does not apply when a sip server is unable to successfully process sip requests for other reasons. Examples, where overload control does not apply -- pstn gate way that runs out of trunk lines. That has lost connectivity. This is a simple overload-control model. It is based on close feedback control. We have in this model--There is a downstream entity both and there is upstream entity that forwards traffic to the downstream entity. There's a monitor that monitors the upstream neighbor that and how much load this entity is receiving from the upstream entity. The monitor needs to be on the downstream entity, and it is generating some low information that can be used to control the load that is forwarded. How much traffic-- and one specific upstream neighbor can send. It can generate messages to specific upstream neighbors. So the control function takes the load that 19 the system is -- sends command to upstream neighbors. There needs to be some element that receives those throttle commands and then implements a well designs behavior. If you have to reduce your traffic by 20 percent, then it needs to reduce the load to the downstream entity. And there also needs to be some algorithms. And the throttle commands -- a slow start, if a throttle goes away. These are all items that have to be implemented. There have been some debate -- New Speaker: On the last slide. Is there is time effort here--like an oscillator--put it on take it down- presumably there is some sort of -- New Speaker: This is something you want to do in the control function. The algorithm that you are implementing-- but this is something you definitely need to consider when you are implementing a control algorithm. New Speaker: This looks like a closed loop in the sense that we are adjusting weight and all that. It is dangerous because you are--we are dropping things. This is- dropping things- since we- pushing all the way to the end is unlikely. I am concerned about how percentage and some other place. Take another metaphor we are building towards. I don't think this is a matter of simulation. The fundamental problem of overload is 20 the-any time you send- you can easily-- the system which is not contributing at all to the overload. It is a diverse Y. I think we need to have a lot more discussion about systems model, load distribution and expecting things to distribute data. If this means dropping, this is not to be done lightly. All indications are that we know that finding the right time constance is not easy. Invariably, pick one that works for one scenario. It is either too aggressive or gives up. New Speaker: The algorithms have to be very well defined. We don't want to mess up different things. We need to understand better how this all works. The idea was to have a little more formalized model. I am not saying that we all know. We know exactly how this should be done. New Speaker: This is sort of comment about basic model to I know that when we were doing a lot of trick work. You got to downstream proxies or gateways. You can't answer that question without knowing if the other one is at 100 percent or 5 percent. What are you trying to optimize. You are balancing more between them New Speaker: You have to have that. New Speaker: I didn't see this model as excluding that. We need to see how that actuator feeds back into the processor. If the problem is the--You can't just tell 21 it to wait. The call is not going to go through. Someone is going to use. I don't know what else you would do. We have no choice but to push back to the edge of the network. New Speaker: I think--this needs to be considered in a low balancing system where it talks to another entity instead of -- New Speaker: This is between 2 entities but the offering entities are talking too and they are receiving down stream traffic from a number of other entities. New Speaker: The overload the entity which goes to upstream only or both upstream and downstream. The entity- the over load entity that only apply to upstream or downstream or to all his neighbors. New Speaker: The assumption is that it receives traffic from the upstream neighbors because these are the ones that are overloading the entity. New Speaker: I am not making assumptions of how the entity distributes with its upstream neighbors. This is not-- this is up to the implementation. New Speaker: I notice that it is not a bit different. How do you consider this relationship generic? New Speaker: This is built into the sip New Speaker: A major impact on this, the multiproduct it could initiate. 22 New Speaker: The fundamental problem I have presenting this as downstream entity is fundamental complexity of problem this leads to confusion--solutions one model is that we have more or less a classical. One low distribution proxies that need to be told where to send requests. They just need to be doing more balancing. That is one important thing that is reasonably safe in some sense. You want to load feedback for example. Assign so much to this one and so much to the other and the remainder to the 3rd one and the other model is things are already going to hell. I want it to drop requests early instead of late. You want to drop them as late as possible. You want to drop Particularly if you can't push back all the way. And the other one depending on--In some cases, you might have the opportunity to buffer instead of drop. Request message, you can short term verse when dropping is not the best solution. New Speaker: I agree. We need to consider the case that we have. I think there are cases where we want to drop messages. The downstream is over loaded and it cannot handle the traffic New Speaker: It is a last ditch effort. New Speaker: We made some simulations where we have increased the buffer size. At one point, if you 23 increase it too much your messages time out while they are in the buffer, and your performance is even worse. New Speaker: The reason to push it as early as possible. The whole problem we are having in a complete overload network. We have done simulations. Rejecting messages, you want to push that forward. Drop the packets early. It is the same basic premise. New Speaker: Comes to dropping calls. From the aspect, from deciding which calls get dropped and what ones do not. The calls get dropped when things fill up, what if it is a 911? The reality is there is only 4 operators. One thing I will say, because there has not been a graceful solution, I think a lot of providers are falling back on control. I will accept 30. And if they send me 31, it will get dropped. And these solutions are being put in place because we have not found a solution for sip control. Other solutions are going to be put in place in the interim. So this has got to be a better solution than blocking calls. New Speaker: There has been remote participant feedback. They are not coming across on mp3. New Speaker: We need to inform all the neighbors of the old entity New Speaker: As opposed to multi? New Speaker: An observation sitting here as 24 nonparticipant. We are still having a lot of arguments over what the requirements are. Let's figure that out before we figure out the architecting on the fly. If you don't agree with the requirements, send a comment to the list on what the requirements really are. New Speaker: At some point- this document- I wonder where this model stuff actually does belong in this document or if it should remain in sip. Is it in the right document? Should we actually be talking about the model and the requirements or the implementation. I assume we will not specify the algorithms at all. Some of the discussion is a bit academic. Or are we going to specify the algorithms? New Speaker: We need to specify some of the algorithms New Speaker: I would argue there was several models of where these components should be; we should pick one. As to whether we specify an algorithm in upstream or downstream. You map queue levels to overload values and the upstream entity does whatever it wants. You let it determine whatever it wants to and gives and load--We need to specify only behavior in one stream. You would -- people could arbitrarily -- that is the primary. You could draw packets or whatever. It is the upstream behavior that you need to specify. New Speaker: You can catch up with him Jonathan 25 New Speaker: I think we need to specify how it is measured in the did you know stream entity first. I think definitely the upstream has to be defined. The downstream if it is going to measure that has to be defined too. What we need to have- a well defined, like a percentage. Standardized gets fed. Standardize an algorithm like when your ram is at then you are -- that is the thing I am saying we don't want to specify that. An entity can be overloading. Let it figure out how those things and over all. And it is only. What you do up upstream with it I think you want to define. Let's try to New Speaker: This is the hop by hop -- New Speaker: My experience with machine congesting control in the wireless control each vendor does it very differently. We should use that flexible to the individual vendor. So we have levels of congestion control and let the vendor decide the best measure New Speaker: This is actually some discussion of the type of feedback that -- you should reduce by percentage of the requests normally forwarded to a given downstream server. I think we have to have more discussions of that. How do we make sure that this -- how does down stream server does not support overload control and how do we deal with servers that also support overload 26 control. New Speaker: We have a requirements document and then lets go on with the discussions that we were having here. New Speaker: I want to talk a little bit about the sip performance draft I wrote in Montreal. The motivation behind it. With the adaption of sip -- we have relied on metrication post dial delay average call hold time things like that. We sat down take a look at those metrics and see how they could be adapted to sip and find methods specifically to the protocol. So I want to talk about the changes within that draft. First it was asked last time to narrow the scope and improve what this draft is focused on. One is in the bench mark and working group. And those are for the server test. Server performance, element performance from aspect of sip. This is an end to end metrication draft. You have a uac and sends a message an invite and you want to understand how long it took to take place. It helps you define -- things like sla and also just how long it takes for messages to be sent across my network. One thing that draft does not take into consideration likes like network impairments, server application problems things like that. It is not intended to address those issues. They will all impact the performance of sip. 27 So a couple of changes from aspect of metrics is that I removed the average house for impact method. There was not an a lot for interested in whether that metric I didn't see any point of it being in the draft. I did add the registration. People asked if I could add that in. It is in there now. There has been some question about that. I changed the session completion delay to session disconnect delay. What does completion mean? I talked about completion in a number of different manners in the draft. I changed that to disconnect. So this is measured from when a buy is sent. I also separated -- in a lot of methods, we have been successful and failed. How do you measure this. One of metrics I have not done that with -- some additional things I had clarification around message retransmissions. If I had rauac that sends an invite. Do I consider the last transmission of invite for the one 80 or do I look at the initial one? I provided clarity around this one. It actually believes that it is probably the first invite that it sends out that it initializes the session to begin with. I provided some clarification of when the timing begins for that. I use the term end to end what does it mean. It -- there is still some confusion on this. It means it is from a point of which you begin to measure it and the device that you have visibility too. It is really 28 not from user -- the actual ta that initiates the call. It could be from point of measurementment which is acting as a uac in a providers network to a uas which is also in the providers network egressing to the uata. This could be capability which is developed within a ta. Also a time begin and time stop. When do we actually begin to measure time? The output metrics and unit of measure, beginning and end. So there has been some- I have gotten a lot of good feedback on the mailer list. There has been suggested changes since the last division. I have primarily defined in the draft all the metrics all the variables from uas perspective. And where it is applicable I am going to add specifically, from the aspect of uas. Also my definition of time begin and time stop I actually came up with through an educated assessment. And I got some feedback from the aspect that in some specifications specifically around things like -- they have a different definition for different begin and time stop. I should align my definitions from time begin and time stop with specifications that have been around for years that have it well defined. And, also, it is amazing sometimes when I write something I can see it clearly. One is registration request delay. I provide a failed example. One of the things is you get a 40 one back. My failed 29 condition is at that the- that the uac gets another one back. I am going to change that to 423 or something like that. The point of this is I am not going to add another failed condition that could possibly happen into the draft. Here is an example of what maybe taking place. It is not exhaustive. These are not all the situations. Additional to that was so-- I- in the draft, I have under session request delay I have failed conditions with that. Should we even measure from failed situations. I dial. I could use. It doesn't matter any address it is totally -- no destination. It would give back a 404. From a uac perspective does it matter that it is waiting for a reorder or air message just the same as if you were placing a call to a successful address and you are waiting for a ring back. When I put it in there, it is intending to say what? I care just as much that I find out that I dialed a wrong number. It is a suggestion. I would like feedback. New Speaker: I think that there is a category of stuff that we need to know that we need some metric for, and I would concentrate some energy on that. And, say, here is something that might be useful. We don't know if they are useful yet. New Speaker: I can do that. 30 New Speaker: We should not formally equip failures like busy and that is just normal, a busy signal. Registration failures are not something regular users should encounter. People use more, my server failed the registration the fastest. That is not terribly useful. New Speaker: I would not brag about that New Speaker: Average registration is 10 seconds. I want to drop failure conditions which are not meant to occur in a normal operation. Not due to normal human type of thing simply because it is unlikely that I am concerned as user or implementer that if my registration fails because of a verification problem that this is an issue. There are some exceptions to that if it is registration failure for- that is different-- I don't want to wait 3 minutes before a response comes back or. New Speaker: I would find what the units of measure are for each of these. And one of the things with that. I didn't have like a 401 registration failure. I actually looked at 10 dot 3 specifies like 4 different conditions that I have never seen. 400, 4 or 3 and a second I put bad credentials in there and it failed. Good point. New Speaker: Draft makes condition methods typically the average. I am just wondering, typically, the right to metric. Average has the -is this the right place to recommend? Consider some other metrics than average. 31 New Speaker: One of the things about average, I provide calculation. I don't specify what time span that you want to have that average over for example. If you want to make it a day or year that is up to you. Here is the calculation, calculated up that metric. New Speaker: You need to put a timer in there. So I'm thinking not to advertise or brag we should have a cut off to define between success and failure. And then that parameter can be changed depending on some. There are some metrics where the units of measure are a time based New Speaker: Things like registration New Speaker: Registration. Okay. New Speaker: Okay. In failure, it is not possible to distinguish, I see a 401, where do I stop looking for a 200. We need a new parameter for that definition. And then my people will wait longer to see it succeeded. It will become a parameter of my test environment. New Speaker: Someone asked me to add in time out conditions which is where I have examples in. I don't have that in all of the metrics so it was suggested that maybe I have that in there is that what you were referring to? I sent the registration request and then I never got a response and then it fails New Speaker: In your example you show you get a 401, and 32 then you get a 200, I think you need a cut off New Speaker: I would like to get some help from bmw, this is where we are trying to write single device performance benchmarks. We do separate terms and methodologies. Make the internet a better place. New Speaker: I want to put in an advertisement. Also, there is an ippm group that is interested in group and Lars and Dan and I are trying to have some discussion about what is the best way to get all the right people and different skill sets. It is not clear at all exactly how we want to do that. New Speaker: I will put another draft revision to this. Where does the draft go from here? I have gotten emails. Shouldn't this be an experiment? Should this be benchmark? We differentiate between those 2 groups New Speaker: What we don't want you to do is stop working on it because we can't decide where we want to go New Speaker: What will say about this draft. It should apply to all applications of sip, I think, not saying that I address every single situation that has ever occurred from sip. This is from 3261 from core singling expectations of sip. It is not for 1 particular area of sip. New Speaker: Do you want us to measure? 33 New Speaker: Find some people that are interested in moving forward. New Speaker: We are not at a point to New Speaker: I will say I am going to get together and talk about the draft from this room and I don't know where we will meet yet but find me and contact me and I will let you know New Speaker: Clarification on privacy mechanism. New draft on clarification privacy mechanism. The problems that this draft is trying to solve that I rc 3323 defines the privacy mechanism for sip. In these, the semantics are defined but they are not clear now. And the target headers to be -- it is not specified and such specification pose this matching between the entity that said privacy header and entity that execute the privacy side and which the progress of the draft are these 2 things the privacy mechanism and to provide guidelines for future specifications and the clarification includes and the handling of for each of -- sip headers of interests -- the recommended behaviors of privacy service for each sip headers when each -- accept in the privacy header. After we submit the draft, the colors need to be clarified. Should the scope be limited to only sip headers or extended to sip 34 parameters. Now draft only includes the sip headers but our recommendation is to extend it to the parameters. The privacy service is to protect a users privacy related information is included in sip message in sudden parameters whether or not a sip header itself it should be obscured by privacy server. Another issue is do we need to clarify where the privacy service should be executed for each prive value. Are we interested? New Speaker: Better than discussion- I would like to have a discussion of whether we want to clarify this or move away from this mechanism and I think Jonathan. I would like to have a-- if we want to move away from mechanisim. Before discussing, people with opinions, I would like them to move up to the mic. New Speaker: I think the current specification of the privacy stuff is unclear. I think it is continuing with this individual for a little bit to get some stuff that is useful is a good thing New Speaker: I posted on this-- on the list. I saw this draft, and I think it is appropriate under the assumption--My feeling is that a lot of changed outside of our rc -- the rest of these mechanisms and we also have a large increase in a number of tools on its own to construct a private message. I would like to see a different model of privacy server. Instead of asking 35 the network to delete on case by case. Give the power in the hands of in point itself to insert or not to insert and make private whatever headers it wants to make private. How a user agent constructs its messages. And how it signals to not make things worse. For every single new header how it needs to be managed. This is a problem with this. That is sort of direction on the. I wrote a draft. This identity proposed this ua based privacy mechanism. That still remains my preference. Regardless of whether or not you still need to know what you apply privacy to. Implementers don't always make the best choices. We need to figure out what the privacy implications are. That point aside, I also continue to believe everything it is best to do privacy at user. We need to realize that. I have a suspicion that there are user agents that will be deployed that will not have that built into them. These can be sent out into the field by a provider that does not have any interest in this. The thing the document should characterize it as an unfortunate position. As long as that is true, we will have that problem. New Speaker: It is completely appropriate for this. There is a large deployment of. So that doesn't mean we will get rid of privacy. We have talked about how when new headers come along we need to-- you can not go back 36 in time. You can't re-create semantics. We should obey certain laws of physics, and we should be fine. New Speaker: I would support this work. We have an all network -- if we clear, we need something that will clearly define these privacy behaviors, especially of privacy header. What we have seen over 20 terminals that we have in our network. It is really a problem. With a terminal vendors, we do not understand at all all of those values. They need to understand the values. This would be helpful for us in general to have this service. It is one of the basic services that we use. It has to operate with -- this would help us to go forward. New Speaker: To address this point; less is more. I am advocating that. Since most of the things that are said in -- it is mute. If you sort of-- what seems to me if you assume that ua can do most of the work on its own. The issues that remain I am trying to withhold my identity. I would take that for the -- all you want is singular value. Network knows not to stick in additional information. I would go so far to say that the only value we need id. That to sort of address John's question on the similar vains. It is not educated by privacy headers at all. I would argue that if you wanted a way to -- less is more. I don't want to 37 have parameters that say Mr. Privacy -- I don't think there is a real need for that. Less is more. Routing to one. I think that is much as we would need. New Speaker: We are not trying to clarify. There is a case where networking. So what is the decision. Should we move on with the way that the direction it is go. I am saying if the interest is completely deprecating. So that it is usable New Speaker: We need to move on New Speaker: I think basically there is interest in that and we have to resolve what to do. It is an interesting field we need have more discussions. I don't see the usefulness of actually poling the group right now. New Speaker: The discussion about the gate way. The use case gate way with all the privacy is done by the gate way. And then there is still need for some additional privacy because any other header we get additional information. Fiver or six headers and nobody understands how to do it. New Speaker: I would like to defer further discussions. New Speaker: I am from -- this is an example from the operation -- first the uac it could be a server: And uri's list can be uri's themselves. It can refuse the handling. If it does so, it sends response code 4095 to the uac. Its response code, refused uri's list. The 38 prints at the example. You can include information about the members of -- when it receives this response code it has not sent out any sip requests New Speaker: So if I am in the uri list server and I-it sounds like an intersection between this and the session policy work. I should be able to say no I am not going to go do that. The uac is likely going to have a relationship between its server. And it should have a pretty good idea beforehand whether it supports this maximum size or supports another domain. Going further and further into-- why am I forgetting this word -- recursion or not and to what depth. So is this something where the uac where they are going to be counting a server. It is not handled and if this is several more requests or one time thing New Speaker: No one time thing. This is a basically they need this kind of functionality they need those refused uri lists to the original mediator and the main person of that list and the origin in both cases is the controlling observer can then make these outgoing requests. New Speaker: I believe that there are a couple of issues the uri can be a different- The number parameters you are talking about behavior is unrealistic. This is something you can do without an extension by sending 39 back a response. Here are a bunch of uri's you can use yourself. New Speaker: This is proposing a use code and the other is the actually means to convey the uri's back to user in the class. That mechanism would need a standardization anyway. It has different meaning anyway, 300. You can actually request uri. This is these are actually the members you want to contact. In a 300. You are providing an alternative location. You are providing a uri of all the friend's of bob. In any case, the discussion we were having on the mailing list basically. This is generally enough to have header field. We want to define the same thing. Those were the discussions we were having basically. New Speaker: I am confused -- the list of friends. New Speaker: It is saying friends I couldn't explode it and these are the list of members -- you are correct. New Speaker: So basically the in scenario doesn't want to act supplies the members back to uac and they can go in individually New Speaker: Here he is using a uac 2 proxy server and the thing is like they need 1 controller proxy server. And in this case, for instance, they would imply the second server would be a controlling proxy server as well. In this session, please explode the uri itself. This would 40 be the traffic between proxy servers actually. New Speaker: I am not sure if this is actually been included in that but looking at the slide the usage seem as little hard to work out. You list the uri lists contents are but they don't know that. There is a probable breakdown. It has to send out a complete list first. And then say these items are the ones that are rejected, you need to enable to uac to send back something useful. New Speaker: It is exactly what the draft defines New Speaker: When it sends the it is uri list it also has the members of the prints. It is not just showing the slide. New Speaker: But if it is not friends in the uri list New Speaker: The use case is. Sends this invite and has bob and friends. Bob is single uri it is okay. Friends is the list itself. The server is saying I can explode bob but not friends because it is list itself. Instead of invite for bob and friends send it for bob, Paul and John. New Speaker: You can't send an invite for 2 uri lists. New Speaker: Can we go through slides and then questions more in the end, is that okay. This is what we already said. This is what we defined. We specified 2 things. And then there is an ipr issue we submitted the draft 41 and then we discovered and now Ericcson has submitted an ipr declaration, questions comments? New Speaker: First comment is that we seem to be going straight into the solutions. I think the problem is in all things around it. There maybe alternative solutions. What would they be for requirements. Why not do it this way. New Speaker: I think we could add this motivation to the daft. I think this work has been done. Okay. What was the other comment. Whether the ua is entitled to the values or not. Obviously it will not work if you are not prepared to the members of this list. New Speaker: Why do you need to have a new header. Probably need to find a new header didn't we define in the -- you can New Speaker: You have to have a flat list and this is a flat list New Speaker: So to speak the points about requirements, I would like to understand the following. This countless why a server reject as request. Communicate specific reason when the user agent needs to take. There is a presumption that in the background. You have to update the list. It seems like it is there but it is missing. Well, obviously, you are uploading lists and the server didn't filter that upload time. It seems 42 like a contrive use case. New Speaker: I agree. It only explains the solution Y. think that would be added to the draft New Speaker: To give the specific case this is the situation where a focus ability, upstream. It doesn't know that within this list to be exploded is enough that it is embedded. You want to go back to simple point of explosion. You have to get the list of members back from downstream. New Speaker: There was error call flow in network diagram. Put the picture in the document New Speaker: Conflow and the requirements otherwise it makes no sense to discuss a solution, any new comment? New Speaker: As a privacy issue there really aren't any privacy issues. If you could subscribe to uri list it -- if you -- you also have to know what all there elements are. New Speaker: We can also do something about privacy New Speaker: Any other comment? Or shall we move on on? New Speaker: Basically, new headers, aren't they going to new status to the sip group. New headers that are not new response codes also go into the sip code. New Speaker: Thank you for reminding us of that. New Speaker: Brian is next. New Speaker: Brian's draft and then P header 43 In Montreal. We had a discussion here there were some people that disagreed actually was to move on with that. We have been waiting to request a publication of that. Brian put together this draft. There were discussions that we had a general mechanism, they don't over lap at all. The p header. If you have a problem with that go back to list and show your support. So Brian, that was actually the whole point to not overlap the 2. So from the Montreal meeting there was an introduction there was some discussion about general problem. There was quick overview if any of you have read, can it be gated. What this draft is trying to do about the general problem we have had had for a long time and the ways people have deployed and the ways these things are breaking, recommendations on how to stop doing these acts make changes to protocol so they are not necessary and explain why it is broken and make sure they will never be broken: Okay so just a quick nonexhaustive list of problems and this is already identified. The. This gives us problem clipping problems -- we don't know which media stream the media stream is coming from New Speaker: Clipping is not a problem due to signaling path being disconnected it is not receiving New Speaker: Clipping as you define in 3960 like slow starts. 44 New Speaker: That is not because New Speaker: Well, true. To clarify the point in clipping typically the media path is optimized for speed the signaling path might be delayed likely to the media path. The next big problem is this same bottleneck problem. Essentially rfc 361 if you have to accept media anybody knows what your offer was. Change the routing behavior for-- this text you were referring to says must be prepared to receive. It does not say render. In practice however ua's are expected to render this. New Speaker: No I have a couple ua's. They will render if they detect that there are many they will not render all the streams. New Speaker: We spent 4 years discussing this. New Speaker: I think we have to be careful that we do not shoot the messenger. All the points are valid. But it is not predictive in terminals today. First one last one try to play them all and it never seem is to New Speaker: If you look at 3960 it says pick one at random New Speaker: Random is not good. Random will get you in trouble and get your customers really pissed and you can get sued. There is a pretty big problem. I think my motivation is we only talk about what is new and what we 45 want to do what is new what we already recommended. Let's do a really-- I was also wanting to call attention to there is a tendency that assuming the world is a particular way. The specs don't say that and they don't say that yet. That is not what they say now. New Speaker: In 3960 it does say that; it does mention it in the context of early media. And I am not trying to reinvent 3960 here. I am trying to close off holes as best we can. Moving on then. We have forking interactions which we obviously know. Okay. Trying to classify some of the problems that we might run into. These roughly correlate to a lot of well known services. We have prerouting -- prepresentation -- ring back things like that. For the purposes of early media are identical. The post presentation is the worst of the bunch. Where you get the mob approach where there are many media streams approaching. After a proxy is going through post presentation stage. No matter what stage it is going to. That is important if you have multiple proxies involved in a particular call. And finally, nonsdp Okay. So the draft moves along into the draft -- which some might think it is a proponent of these mechanisms. If you have seen others, email me. People try to cope with the problems of I am getting multiple media streams 46 multiple sdp answers. I need to make sure that my client behaves in a predictable manner. Stripping or delaying the sdp -- couple different ways of working. One would be if you sent an sdp the proxy simply drops it. The terminator. It may reinsert. Delay -- the proxy has some media to the proxy that it is 81 controlling. It delays, it makes it look like. New Speaker: This proxy sdp stripping, first of all a proxy is not allowed to do that. Second I want to ask how even if this were if we thought this was a useful, why is this a good thing, why would this help? How could this possibly call your early media problem to be better. New Speaker: I am not proposing that it does. The reason that I have seen it used. I am not going to send your sdp back New Speaker: It does not cause it to stop. My problem is you are listing this under coping mechanism, this is broken, just say, don't do that, it is illegal. New Speaker: I don't think it is illegal if. I didn't get into 3 a.m., this shouldn't say proxy, it should say -- I have seen people use this. To make sure there particular media stream gets presented to a client New Speaker: You can call it something else but it is not a coping mechanism 47 New Speaker: I think a great source of confusion and I have talked to Brian before that it gives the draft the impression that coping mechanisms are endorsed ways to deal with early media. It is actually bad coping mechanisms that, there still there and I think the way to address this is in let's say we have a review of this draft to make it a lot clearer than right. I think the reluctance of the group. New Speaker: I have a similar comment I find it really hard to extract the problem here and some of it is very sort of enumeration of bad things people do for all kinds of issues but unless you are proposing them or whatever I don't see how it is helping it is hurting what is not yet addressed against 3960 how do I address multimedia streams. Then that needs to be stated. If that is not what you are trying to do -- I still don't understand. Let's advance to next slide. Desired result of draft. I am not advocating any of the broken behavior. I am trying to highlight it to the group. This is what people think is acceptable behavior as far as dealing with early media. We know there is problems with it. I see it in implementations and I see it in other design. And I think it is something we should say stop doing this, this is what you are going to break. 48 New Speaker: Helping to select each media stream do I render-trying to solve. And this is something that I really believe. It is not completely. It could be served with and the 3rd one is actually trying to provide a mechanism and having -- New Speaker: There are some boxes that will never do any of those things that you just listed. We need to say if you are trying to say that if you are dealing with these boxes. Don't have your client -- and so even if we say there is no changes that we want to make to the protocol. I put some stubs in for conversation. We don't think we can't change. I think it is useful kind of like hitchhikers guide. This is the way these things should be built together. We can end the endless discussion in other groups that people thinking they are the first person to have there clients behave a particular way or have there proctor behave a particular way. It gets specified a particular way. New Speaker: I would like to have these conditions implemented separately. New Speaker: I think in order to-- I think we can split the 2 fundamental open issues I guess here what needs to be fixed. Okay. And I think if there is something that is broken and basically. Right now it is very arbitrary. So if there is something we can do there 49 lets try to find a solution for that. And the second point on the discouragement of do we want to publish this or not. A lot of people don't agree with us publishing a spec that shows all the bad things. Maybe we shouldn't publish it to encourage a lot of other bad ideas. If we separate those 2 we could progress. New Speaker: I was going to say a similar thing some of the stuff reads like I am going to forget about it and lets develop another. We were supposed to have a speck that does everything that we just described. It says play distribution this doesn't work here is the reason it doesn't work that is not what it purports itself to do. If we have a problem with playing figuring out what street to play then describe and propose a solution. New Speaker: As I said, at least 4, 4 different goals. The other the media correlation is completely different. New Speaker: The point of the draft the way it was laid out. Okay. If you are out there implementing something and you are not up on all the rfc's. There are quite a bunch that this thing references. I tried very hard to refer back to 3960 to not try to resolve the things that are in 3960 there are no discussions. New Speaker: I would like to call the attention to the report; the summary of answers that I got back to ask the ua's what they did for multimedia streams. The 50 answer the point of going through the answers that you see here we have created a one-stop shop. The implementers -- we shouldn't beat people with it. It doesn't seem to change from sip it to sip it. New Speaker: Basically would be to discuss the issue separately. Encourage this discussion New Speaker: If you have implemented 3959 please raise your hand, the early session New Speaker: The next session will be tomorrow, Tuesday. *******