Subject: [martini] GIN temp GRUU

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jun 2010 11:01:15 -0600

I'm not OK with requiring out of band provisioning for K_e2. This would be a nightmare in practice. Could it be passed in the register response?

Having this as optional does not really work for me because most the US based customers doing PSTN replacement believe they are required to provide anonymous call. 

Overall, looks workable yet complicated - I wish there was a simpler way but I could live with this.

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Jun 2010 12:33:31 -0500

> I'm not OK with requiring out of band provisioning for K_e2. This would be a nightmare in practice. Could it be passed in the register response?

I don't think so. Even for a 1024-bit key (which is pretty much the 
smallest RSA key one would consider using), you're looking at 171 bytes 
once you've base-64 encoded them. 2048-bit keys, which are not 
unrealistically large, would be 342 bytes long.

I think these would pose very real problems in a REGISTER response.

I did briefly think about using draft-ietf-sip-certs to get keys, but 
that introduced even *more* complexity. Plus, it can be added on as an 
extension at a later date if people really want it. But I think we'd be 
really getting out way in front of demand if we did that now.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jun 2010 11:37:43 -0600

> I think these would pose very real problems in a REGISTER response.

I don't see why that size is a problem. I get SDP in responses that is larger than this all the time.

---

From: Adam Roach <[email-masked]>
Date: Wed, 16 Jun 2010 12:43:39 -0500

> I don't see why that size is a problem. I get SDP in responses that is larger than this all the time.

To put it another way -- you could fit an awful lot of phone numbers 
into 342 bytes (if packed using some sane approach), but people were 
freaking clean out of their skins at the prospect that we might even try.

It would be easy to specify, of course. I just want to make sure that 
we're not going to have another knock-down-drag-out fight over response 
sizes.

/a

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 16 Jun 2010 12:09:42 -0600

On Jun 16, 2010, at 11:43 AM, Adam Roach wrote:

> To put it another way -- you could fit an awful lot of phone numbers into 342 bytes (if packed using some sane approach), but people were freaking clean out of their skins at the prospect that we might even try.

Sure,  we only got to GIN due to fairly unlikely requirements combined with strange beliefs about compression - can't say I like it but I could live with it. GIN does seem like a lot of work just to avoid turning on DynDNS on my NAT but whatever.  I see no problem with stuffing a 1500 bit key in the responses and if people think that is going to fail, it seems that some pretty typically INVITES are also going to fail.  

> 
> It would be easy to specify, of course. I just want to make sure that we're not going to have another knock-down-drag-out fight over response sizes.

I've got 3 gallons of shed paint left but can only transport it over UDP.

---

From: Dean Willis <[email-masked]>
Date: Wed, 16 Jun 2010 20:34:53 -0500

On Jun 16, 2010, at 1:09 PM, Cullen Jennings wrote:

>
> Sure,  we only got to GIN due to fairly unlikely requirements  
> combined with strange beliefs about compression - can't say I like  
> it but I could live with it. GIN does seem like a lot of work just  
> to avoid turning on DynDNS on my NAT but whatever.  I see no problem  
> with stuffing a 1500 bit key in the responses and if people think  
> that is going to fail, it seems that some pretty typically INVITES  
> are also going to fail.

Just to reiterate, DynDNS is inadequate, as my NAT doesn't know which  
of my phones/pbexes to redirect port 5060 for, and it works much  
better if I use a real publicly-reachable proxy to register with, ala  
outbound. MARTINI fits into this space, specifically for PBXes with  
more than one DID number.

--
Dean

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 17 Jun 2010 09:28:41 -0600

> more than one DID number.

Yah - I've lost that argument. I should not have brought it up.

---

From: Martien Huysmans <[email-masked]>
Date: Wed, 30 Jun 2010 13:09:32 +0200

Hi

In the mailing list also the option of a privacy service provided by the SSP
was suggested, which when acting as B2BUA, would ensure that a party remains anonymous.
No comments were posted on this suggestion.
Can this be a viable alternative?

Regards Martien

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: Wednesday, June 16, 2010 7:01 PM
To: [email-masked]
Subject: [martini] GIN temp GRUU

_______________________________________________
martini mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/martini

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jun 2010 20:24:13 -0400

> Can this be a viable alternative?

I didn't see that mail - can you provide a reference?

What privacy service spec/features does this imply?

To provide full functionality, for every dialog it would have to insert 
a B2BUA, create a temp gruu to replace the supplied contact, and then 
route out-of-dialog requests for that temp-gruu to the calling UA. And 
it would have to inactivate that temp-gruu at some suitable time.

The real gruu mechanism seems less trouble.

	Thanks,
	Paul

---

From: Martien Huysmans <[email-masked]>
Date: Thu, 1 Jul 2010 08:26:07 +0200

The mail was called: GIN and anonymous GRUUS

I was not considering "out of dialog requests". 
Is that a requirement for anonymous calls?

With a B2BUA in place, perhaps gruu would not be needed at all.

/Regards Martien 

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Thursday, July 01, 2010 2:24 AM
To: Martien Huysmans
Cc: Cullen Jennings; [email-masked]
Subject: Re: [martini] GIN temp GRUU

Martien Huysmans wrote:
> Hi
> 
> In the mailing list also the option of a privacy service provided by 
> the SSP was suggested, which when acting as B2BUA, would ensure that a party remains anonymous.

To provide full functionality, for every dialog it would have to insert a B2BUA, create a temp gruu to replace the supplied contact, and then route out-of-dialog requests for that temp-gruu to the calling UA. And it would have to inactivate that temp-gruu at some suitable time.

	Thanks,
	Paul